Pandora Thoughts On The Repository And Pnds


lomaxx

Active Member
Joined
Sep 22, 2008
Messages
747
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. :p

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. :D So i'll end this for now.
 
I'm off to a meeting so didn't read too much, but the very reason we started thinking about making something like pnds is because we needed a system where cool apps could be set up and used easily, with the OS booting from NAND. We also needed to support the fact that most content will be on removable media (app coudl appear/disappear randomly, and want data to always be in predictable locations, and other various features of the pnd concept. But the root cause is due to NAND being small :) (ie: There are various systems around to help installing to removable media work, but in my (limited) experience they seemed to be unstable in a lot of respects, and can get really messy and weird .. consider, if you're booting from SD1, and install an app to SD2, and then yank the SD2 out.. what happens? What if you're using a repo and install a lib to SD2 and yank it out, but the dependant app is on SD1? However, if apps are ported properly and we're using a pandora-repo, then those issues should be lessened in the same way they are lessened in using a pnd.. its a developer discipline question, not a tech question. Anyway, I digress as I'm typing way too quick :)

We pretty much could not presume to require people to use an SD to boot from (and many people will want dual SD slots and not havingt to loose one to the OS .. booting from SD pretty much means that SD is non-removable :)

So your first assumption up top that most people will or are booting from SD is in question; you can almost bet that currently, very few would be doing that; I'd be willing to guess that in the future this would still be the case -- most people (even Pandora users :) aren't hardcore; they'll turn the unit on and use it, and add apps to it; the chance they will want to (when they do not _need to_) install the OS to SD just seems unlikely. (But you never know, we do have a much higher nerd %age than most devices.)

We do hope to (soon) have a repository for doing firmware updates, and since we need to keep the pnd-idea going for folks using the device in the expected fashion, we have the app-store etc. A repository could also have the apps in non-pnd form, but the apps would have to be prepared a little differently (handle their own appdata-redirection since it wouldn't be automatic anymore), which runs the risk of conflict since you now have 2-3 or mor evariations of a single app, acting differently. So not sur eI like the idea of the same app in multiple ways, just due to confusion, but at the same time, for SD booters, it'd be nice if a pure normal install method could exist. Stuff like that .. we'll have to see how things evolve to see if its worth pursuing :)

Stuff like system utils should likely be in the repo as you say; its just we don't have a repo right now, so there you go :) background killer probably should not be needed anymore at all (since hf#3?), but that sort of thing is very small anyway. (pnd's do make things pretty easy, but a repo is pretty darned easy too, and makes updates easier (if you have wifi working, which is not a sure thing.))

Anyway, we've beat this to death many times in the forums; I'll have to read-up your message, but in summary -- if you'r ebooting from SD, its a whole different story, but I don't think many people will actually be doing that. If everyone does start doing that, it does bring up lots of questions all over the place :) We've been torn for the entire lifetime of the project how to handle things .. wtih pnds, with pnds + non-pnds, without pnds, and all kinds of variations. Its a tough one, not an easy path. (And perhaps the solution is really to have multiple paths, we'll see :)

jeff
 
Lomaxx said:
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.
This is actually where your idea falls apart. The PND system was designed for those who are not booting an OS off the SD card, since most users will not. If you are the kind of person who would like to boot from SD card, then you have very little need for PND files (other than it might be the only way some applications are made available).
You're booting from SD card, by all means, install Firefox or anything else you want. I like being able to hot swap my SD cards without worrying about the OS, so I'll stick with PND files. There's room for both setups to coexist.
 
Last edited by a moderator:
As has been said, not everyone will boot from SD. I, however, am planning to boot from SD, but I still like the idea of PNDs that I can use from my second SD slot. For example, I envision having a card devoted to media, holding all my videos and music, along with PNDs to watch and listen to them.

However, I do agree that it would be nice for us SD-booters to be able to install programs through the package manager. Everyone is busy PNDing-up apps, but they aren't considering packaging them into ipks. I can't blame them, that's a lot of extra work. So in the interest of making it easy to do both, I wondered if it might be possible to extend bitbake so that it could produce PND files in addition to ipks. Each developer could create one bitbake recipe that could be uploaded to a central store and automatically built into both package formats. Of course, I know very little about bitbake, so I have no idea how impossible this is. Could someone tell me?
 
Itd probably be easier to convert (wrap) pnds to ipks? Just another sh script we could provide, then a method to upload that to the repo?

Jeffphone

Btw.. If you boot from sd1 you can still put video and pnds etc there, and could even partition off a fat fs if you wanted
 
Is there some instruction available on how to create a new package within the pandora-repository and/or how the repo is maintained in general? I'm not sure where i should start searching for it, beside in the wiki.
 
As a Win user, I've so very little idea what to do most of the time and really do enjoy the .pnd system. I imagine as the Pandora group expands there is a fairly good chance many more like me will follow, with more money to spend on a hobby then brains (my case) or time (most others) to figure out more then a .pnd.

So, I'm honestly hoping based on what just this thread that most developers stick to the .pnd system.
 
Back
Top