Intro: This one grew a bit long while writing, but it helped me to clear some things out for myself. Maybe someone will find it still useful.
I know that there are various way of approaching this, but - at least for my own purposes - i've been thinking about a little different way of handling PNDs. The ideas are based on a Pandora-setup, where you boot the OS from a SD-card (which i suppose is what most people are or will be doing) and because of that are not too short on OS-related storage.
For them it would make more sense IMHO to additionally offer most of the applications like musicplayers (like deadbeef), system-tools (like background-killer) or emulators through the pandora-repository instead of using PNDs for them. Maybe this is planned and the reason is that setting up a pnd is easier than creating a package, especially if it depends on libraries, which are not in the repository in the needed version. However installing and updating these packages would be easier then. And i see no benefit in using PNDs, since such applications usually stay installed. All this is maybe not that much of a new idea, but i wanted to bring it back into memory of people.
In general i wonder how the Pandora-repository could be populated in the fastest way. Using the extend tools is nice and a a chroot_environment powerful option of Linux. But using it seems to be like a little quick work-around. For example: when i left the chroot-environment, then there are still tons of mounts left, which give me the feeling of an untidy system. I could try to directly boot arm-debian or -gentoo or what ever, but that probably wouldn't work easily or at all (wrong kernel, drivers, ...) and would put me into kind of a side-position as i would would miss system-updates that are done within the Pandora-repo. On the other hand converting and updating everything that works from arm-debian into the pandora-repository is too much work for the rather small Pandora-communtiy. What's the best way of solving this? Would it work to merge both repos by using something like virtual packages within Pandora-repo that point to the debian-repo? At least for the non-system-critical libraries and applications. How could someone with not-too-deep knowledge contribute to growing the Pandora-repo? Shouldn't we all be working in one repo instead of trying to get three or more different ones running?
Back to the PND-system. I've been wondering where exactly I would use PNDs. Basically it's nice for large, non-default applications that you do not want on your OS-SD-card installed. Stuff like Firefox (as non-default browser) or OpenOffice which you might want to use every now and then, but probably is not your default writer (unless you got a very large OS-SD-card), and most of all for games (but NOT an emulator-programm itself). These together with data like music, movies and (open-street)-maps i would put on several cards, which could then easily swap. All the later-mentioned stuff does not need PNDs though.
So, again, i see most of all three categories for PNDs:
- new test-builds. Once it works nice, seems to be of everyday-use for most and is not too large there should be a package in the repo available
- for large programs which are unlikely to be the default (Firefox/OpenOffice), but they still might want to be integrated in the repo.
- games (even here some people might prefer to permanently install them and repo could offer those who do not harm the license)
All 3 points could use a mechanism where programs are available in both (PNDs and repo). For them it would be nice to have an automatism where you quickly transform packages into PNDs. Something that asks how you want to install them. Or just leave dpkg the way it is and additionally offer a script that creates PNDs from packages in the repo (uninstalled or installed). So that everything (except for very new beta-releases maybe) can be found in the repo as long as it competes with it's liscence. Also there could be a way to scan an inserted card2 for updates for installed PNDs based on the repository-database and perform the update on demand.
Now for the last point: games. From the technical point of view (regarding installation), games can be seperated into two parts: One, which is small, with the code- and configuration part that needs updating and can be spread through the repository. And a second, large one containing the game-data (like graphics and music). There are games (mostly native ones) where this can not clearly be seperated. For example in "Battle of Wesnoth" where an update might also bring changes to graphics and sound. But for all games that use an interpreter (reminiscence, d1x, quake) or an emulator this should work perfectly as the game-data of such old games is fix. Even for the example of "Battle of Wesnoth" this seperation could still make sense to seperate them, because the data-section might needs fewer updates and so bandwidth could be saved and updating speed up. It wouldn't make much sense IMHO to install the program-part of BoW on card1 and the data on card2, although even that would be possible.
The remaining two type of games (for interpreters and emulators) mostly depend on data that can not be shared legal. However the interpreter and emulator itself could be still maintained through the repo. Again with the option to build PNDs out of them. Bios, kickstarts, disks, roms need to be left out of course. The owner of these would have to install them to any of the two cards he wants - someone might want to choose to leave bios/kickstarts on the OS-SD - and configure the paths in a conf-file which can be saved on the OS-SD (home-directory).
For interpreters that support many games (like SCUMMVM) and for emulators a system like PNDs might be helpful, too. Though i am not sure if simple archives (tar.gz,zip,7z) would be enough. I am thinking of a directory-structure for the game-data of these on the second SD-card of the structure:
/games/amgiga/
/games/neogeo/
/games/mame/
/games/atari2600/
In these you put in one PND-alike file (or archive) for each game, which of course the owner has to create on his own and that contains a emulator-unspecific information-file for running the game (if needed) and game-files/disc-images). The goal is to be able to assign a certain emulator to a specific directory and directly run the game without the need of setting several options. Just by choosing the pnd-file or archive through a lean, game-platform-unspecific launcher. Unfortunately many emulators do not support the option to pass configuration-parameters or a a complete configuration-file at all. The need for command-line-parameters are underestimated.
Instead every emulator comes with it's own gui. Which is nice, but doesn't let you start a game with one (double-)click.
Well my head starts spinning and probably everyone has stopped reading up to here anyway.
So i'll end this for now.
I know that there are various way of approaching this, but - at least for my own purposes - i've been thinking about a little different way of handling PNDs. The ideas are based on a Pandora-setup, where you boot the OS from a SD-card (which i suppose is what most people are or will be doing) and because of that are not too short on OS-related storage.
For them it would make more sense IMHO to additionally offer most of the applications like musicplayers (like deadbeef), system-tools (like background-killer) or emulators through the pandora-repository instead of using PNDs for them. Maybe this is planned and the reason is that setting up a pnd is easier than creating a package, especially if it depends on libraries, which are not in the repository in the needed version. However installing and updating these packages would be easier then. And i see no benefit in using PNDs, since such applications usually stay installed. All this is maybe not that much of a new idea, but i wanted to bring it back into memory of people.
In general i wonder how the Pandora-repository could be populated in the fastest way. Using the extend tools is nice and a a chroot_environment powerful option of Linux. But using it seems to be like a little quick work-around. For example: when i left the chroot-environment, then there are still tons of mounts left, which give me the feeling of an untidy system. I could try to directly boot arm-debian or -gentoo or what ever, but that probably wouldn't work easily or at all (wrong kernel, drivers, ...) and would put me into kind of a side-position as i would would miss system-updates that are done within the Pandora-repo. On the other hand converting and updating everything that works from arm-debian into the pandora-repository is too much work for the rather small Pandora-communtiy. What's the best way of solving this? Would it work to merge both repos by using something like virtual packages within Pandora-repo that point to the debian-repo? At least for the non-system-critical libraries and applications. How could someone with not-too-deep knowledge contribute to growing the Pandora-repo? Shouldn't we all be working in one repo instead of trying to get three or more different ones running?
Back to the PND-system. I've been wondering where exactly I would use PNDs. Basically it's nice for large, non-default applications that you do not want on your OS-SD-card installed. Stuff like Firefox (as non-default browser) or OpenOffice which you might want to use every now and then, but probably is not your default writer (unless you got a very large OS-SD-card), and most of all for games (but NOT an emulator-programm itself). These together with data like music, movies and (open-street)-maps i would put on several cards, which could then easily swap. All the later-mentioned stuff does not need PNDs though.
So, again, i see most of all three categories for PNDs:
- new test-builds. Once it works nice, seems to be of everyday-use for most and is not too large there should be a package in the repo available
- for large programs which are unlikely to be the default (Firefox/OpenOffice), but they still might want to be integrated in the repo.
- games (even here some people might prefer to permanently install them and repo could offer those who do not harm the license)
All 3 points could use a mechanism where programs are available in both (PNDs and repo). For them it would be nice to have an automatism where you quickly transform packages into PNDs. Something that asks how you want to install them. Or just leave dpkg the way it is and additionally offer a script that creates PNDs from packages in the repo (uninstalled or installed). So that everything (except for very new beta-releases maybe) can be found in the repo as long as it competes with it's liscence. Also there could be a way to scan an inserted card2 for updates for installed PNDs based on the repository-database and perform the update on demand.
Now for the last point: games. From the technical point of view (regarding installation), games can be seperated into two parts: One, which is small, with the code- and configuration part that needs updating and can be spread through the repository. And a second, large one containing the game-data (like graphics and music). There are games (mostly native ones) where this can not clearly be seperated. For example in "Battle of Wesnoth" where an update might also bring changes to graphics and sound. But for all games that use an interpreter (reminiscence, d1x, quake) or an emulator this should work perfectly as the game-data of such old games is fix. Even for the example of "Battle of Wesnoth" this seperation could still make sense to seperate them, because the data-section might needs fewer updates and so bandwidth could be saved and updating speed up. It wouldn't make much sense IMHO to install the program-part of BoW on card1 and the data on card2, although even that would be possible.
The remaining two type of games (for interpreters and emulators) mostly depend on data that can not be shared legal. However the interpreter and emulator itself could be still maintained through the repo. Again with the option to build PNDs out of them. Bios, kickstarts, disks, roms need to be left out of course. The owner of these would have to install them to any of the two cards he wants - someone might want to choose to leave bios/kickstarts on the OS-SD - and configure the paths in a conf-file which can be saved on the OS-SD (home-directory).
For interpreters that support many games (like SCUMMVM) and for emulators a system like PNDs might be helpful, too. Though i am not sure if simple archives (tar.gz,zip,7z) would be enough. I am thinking of a directory-structure for the game-data of these on the second SD-card of the structure:
/games/amgiga/
/games/neogeo/
/games/mame/
/games/atari2600/
In these you put in one PND-alike file (or archive) for each game, which of course the owner has to create on his own and that contains a emulator-unspecific information-file for running the game (if needed) and game-files/disc-images). The goal is to be able to assign a certain emulator to a specific directory and directly run the game without the need of setting several options. Just by choosing the pnd-file or archive through a lean, game-platform-unspecific launcher. Unfortunately many emulators do not support the option to pass configuration-parameters or a a complete configuration-file at all. The need for command-line-parameters are underestimated.
Well my head starts spinning and probably everyone has stopped reading up to here anyway.