Apt Repositories For Pandora

[BookTracker]

guys it probably works like this:

nand - libfile.bla
sd-nothing
when u set the union(insert your SD),
sd gets libfile.bla
lets say libfile.bla2 comes out,
it should overwrite the libfile.bla, which really means that it copies libfile.bla2 to the sd card, and leaves libfile.bla on the nand.
so like everyone said, with the sd you got your system, without it... out-of-the-box pandora.

so in other words, i suppose if u got 2 files with the same name, the one on the sd would be favored.
(so lets say if you insert another sd card, and want latest verions, you would have to update again. but is that a problem? )

this is how i think it would work(how ti usually does, i guess...), correct me if wrong.

Yes, that would work fine, but that means you'd be wasting space on the SD card. Every time a package in the firmware is updated, the new package would be installed on the SD card. That's what I meant by never updating the NAND. 256MB at most (more or less depending on compression) isn't really that huge of a deal considering how cheap 16GB SD cards are now, but nonetheless it's still a waste of space.


i would consider it a safe choice, besides what we want is functionality i think. and libs are usually small.
plus every version beyond the one following the out of the box one, would be updated normally(on top of the version inside the SD card). so its not tooooo much a waste, for a functional reality right?
like said before sd cards are a given, and that would protect 'the original functionality' of the out of the box version, so you can mess with your anyway you want. ^^

cheers

 

[zodttd]

I'm very much in support of an APT based repo software such as Cydia for the iPhone. If you want to see package distribution done right, check out Cydia by Saurik www.saurik.com. If we lean towards Ubuntu on Pandora, this is definitely a strong possibility.

I haven't been able to read all 8 pages of this thread yet, so I'm not up to speed with the conversation here. I just know I've been pushing the idea of a Cydia-like app on Pandora and seeing if gp2x.de could maintain the repo's.

This model works great on the iPhone, and it should work very well with Pandora too.

I love this idea.

 

[AireTamStorm]

Yes, that would work fine, but that means you'd be wasting space on the SD card. Every time a package in the firmware is updated, the new package would be installed on the SD card.
Negative. It would only go on the SD card case SD card was mounted, only on NAND if not.

There is one problem I'm running into. If you update the NAND the packages on the NAND will be out-of-sync with the SD card's db. The fix is fairly easy, though. You delete the SD cards' db before mounting the union and rebuild it from the one on NAND. The mount script for the SD card could be made to do this, so I do not think it is a big concern, but still notable.

 

[BookTracker]

Yes, that would work fine, but that means you'd be wasting space on the SD card. Every time a package in the firmware is updated, the new package would be installed on the SD card.
Negative. It would only go on the SD card case SD card was mounted, only on NAND if not.

There is one problem I'm running into. If you update the NAND the packages on the NAND will be out-of-sync with the SD card's db. The fix is fairly easy, though. You delete the SD cards' db before mounting the union and rebuild it from the one on NAND. The mount script for the SD card could be made to do this, so I do not think it is a big concern, but still notable.

cant u just o what i suggested, where if file named X is present in both systems, the sd takes precedence over it.
(read my posts up above).

 

[AireTamStorm]

There is one problem I'm running into. If you update the NAND the packages on the NAND will be out-of-sync with the SD card's db. The fix is fairly easy, though. You delete the SD cards' db before mounting the union and rebuild it from the one on NAND. The mount script for the SD card could be made to do this, so I do not think it is a big concern, but still notable.
cant u just o what i suggested, where if file named X is present in both systems, the sd takes precedence over it.(read my posts up above).

No.

If the NAND has Packages A,B,C and you install program D on the SD card, the DB containing information regarding A,B,C will be copied and D added to it. Thus, your SD card database contains A,B,C,D.
You remove the SD card and add E, delete B on NAND. NAND's DB contains A,C,E.
When you re-insert the SD card, its DB still contains A,B,C,D, when the NAND copy is A,C,E.
So, you delete the SD DB, copy the NAND DB to the SD card. SD card now contains A,C,E.
You rebuild the database, and now we're finally in sync with A,C,D,E.

 

[twent4]

- As the firmware resides on the NAND, those updates will work via a package manager. If you're online, the firmware can be automatically updated using the package manager.

Ok, awesome! I was just gonna suggest something similar... being a linux user, but not a coder, i think the self-contained approach is great. APT is great and all, but i have absolutely no idea what to do in case there's archive corruption/version mismatch.

I think most of us should be past the point of complaining about files being 5m instead of 200kb.

 

[Megamixman]

Ok, So I may sound like a broken record, but pacman seems like a very good solution to this, albeit the fact that there are no pacman packages for ARM. The main reason is that the local DB is not stored as a single file, but rather as a folder which works very well for such a union mount. If package A is on the SD, it's corresponding delimiter file in the local repository file is on the SD. If it's on the NAND, the delimiter is on the NAND.
Pacman works quite well. The only real downside to pacman is that there are no good GUIs for it ( with the exception of shaman, which is for KDE4) in comparison to apt. On the other hand it is extremely fast and reliable, while providing a powerful interface. There is a PackageKit backend in development for it, but that is as a whole still a ways off. If anything, I would suggest that developer look into Arch Linux and try out pacman before writing it off.

 

[BookTracker]

There is one problem I'm running into. If you update the NAND the packages on the NAND will be out-of-sync with the SD card's db. The fix is fairly easy, though. You delete the SD cards' db before mounting the union and rebuild it from the one on NAND. The mount script for the SD card could be made to do this, so I do not think it is a big concern, but still notable.
cant u just o what i suggested, where if file named X is present in both systems, the sd takes precedence over it.(read my posts up above).

No.

If the NAND has Packages A,B,C and you install program D on the SD card, the DB containing information regarding A,B,C will be copied and D added to it. Thus, your SD card database contains A,B,C,D.
You remove the SD card and add E, delete B on NAND. NAND's DB contains A,C,E.
When you re-insert the SD card, its DB still contains A,B,C,D, when the NAND copy is A,C,E.
So, you delete the SD DB, copy the NAND DB to the SD card. SD card now contains A,C,E.
You rebuild the database, and now we're finally in sync with A,C,D,E.

thats why you need to have the sd as a front and not the nand, avoids all troubles and you dont need to re-write anything all the time.
(plus keeps the nand safe and in its original form, for stability issues. like a secure snapshot. and you can mess away with the sd card, no probs...)

cheers

 

[johnx]

Hmm...unionfs seems all well and good, but if you intend to keep the NAND in the officially recommended setup (ie, following official "firmware" updates only) while tracking distribution updates on the SD card, you'll soon find that you're saving very little space by using unionfs while running into all sorts of interesting database inconsistencies whenever you update anything on NAND. I know booting from SD seems like "wasting space" but it really will be easier in the long run I think. If it makes you feel better you can think of the NAND as your "rescue" system, should something go wrong with your rootfs on SD. Just my 2 cents from someone who's been in a similar situation before with different embedded Linux devices.

 

[quadomatic]

I would like a apt repo for Pandora, but I'm not sure that really is necessary. It probably would just be easier to use the file archive.

Either way, you still get to download apps straight to your pandora, which I think makes things a whole lot simpler.

 

[cosam]

If the NAND has Packages A,B,C and you install program D on the SD card, the DB containing information regarding A,B,C will be copied and D added to it. Thus, your SD card database contains A,B,C,D.
You remove the SD card and add E, delete B on NAND. NAND's DB contains A,C,E.
When you re-insert the SD card, its DB still contains A,B,C,D, when the NAND copy is A,C,E.
So, you delete the SD DB, copy the NAND DB to the SD card. SD card now contains A,C,E.
You rebuild the database, and now we're finally in sync with A,C,D,E.

I'm missing where you get the data for package D from, if you delete the SD card's database.

 

[Tor]

If the NAND has Packages A,B,C and you install program D on the SD card, the DB containing information regarding A,B,C will be copied and D added to it. Thus, your SD card database contains A,B,C,D.
You remove the SD card and add E, delete B on NAND. NAND's DB contains A,C,E.
When you re-insert the SD card, its DB still contains A,B,C,D, when the NAND copy is A,C,E.
So, you delete the SD DB, copy the NAND DB to the SD card. SD card now contains A,C,E.
You rebuild the database, and now we're finally in sync with A,C,D,E.

How do you rebuild the database? 'D' is now installed on the card, but there's no reference to it in the database because you copied the NAND's database to the card (so that it now shows A,C,E). I don't see how you can rebuild the database, all the information about D _was_ in that original database..

 

[cosam]

Ok, good news on the database front. By the looks of it, the database can be merged reasonably easily if that turns out to be necessary. It's all text files and with the package status information at hand, it should be possible to merged changes on the NAND database into the SD one without too much work. This would solve the problem of updating the NAND without SD present.

However, I've been messing with UnionFS and have hit a problem. All the examples of using UnionFS for root involve making the union from initrd before root gets mounted and init gets started. Has anyone figured out how to (re)mount root as a union on a running system? Without this you'd need to reboot the change the SD card. Or was that the idea in the first place? I could live with it, as I was planning on leaving the same SD card in the system anyway, but I can imagine it's not ideal for others.

 

[AireTamStorm]

However, I've been messing with UnionFS and have hit a problem. All the examples of using UnionFS for root involve making the union from initrd before root gets mounted and init gets started. Has anyone figured out how to (re)mount root as a union on a running system? Without this you'd need to reboot the change the SD card. Or was that the idea in the first place? I could live with it, as I was planning on leaving the same SD card in the system anyway, but I can imagine it's not ideal for others.
Ah, you found a solution faster than I did. Mounting the union on / may not be a great idea, it may be better to mount the folders underneath / individually and selectively in order to enable on the fly unmounting of the SD card. Example:

Instead of /mnt/sd/pandora/ => /
/mnt/sd/pandora/bin => /bin
/mnt/sd/pandora/etc => /etc
/mnt/sd/pandora/usr => /usr
/mnt/sd/pandora/sbin => /sbin
/mnt/sd/pandora/opt => /opt

As we also do /not/ want to union mount over /dev.

 

[cosam]

Mounting the union on / may not be a great idea, it may be better to mount the folders underneath / individually and selectively in order to enable on the fly unmounting of the SD card.

I was kinda hoping to avoid that, but it would definitely work. Are you actively working on getting this working right now? I'm thinking of making a proof of concept for the database part, but there's no sense in recreating each other's work.

 

[kloplop321]

I don't think it would be too necessary, it isn't like the emulation software will have a high chance of using a custom library, but debian based packages are good for handling dependencies, and of course we don't want any "hell" going around because you deleted one.

 

[AireTamStorm]

Mounting the union on / may not be a great idea, it may be better to mount the folders underneath / individually and selectively in order to enable on the fly unmounting of the SD card.

I was kinda hoping to avoid that, but it would definitely work. Are you actively working on getting this working right now? I'm thinking of making a proof of concept for the database part, but there's no sense in recreating each other's work.

I am somewhat busy, but in my free time I am. I'm probably going to assemble a VM image to play with. If you want ssh access, I can give it to you.

 

[conso]

People will find a way to activate real package-management on whatever distribution the pandora will use. I'm not really happy with the decisions made here behind closed doors, but it's not really tragic. If one wants, it should be really easy to use apt/similar for apps and PXML for games.

Linuxusers will be a big part of this community (a lot of people came here only because of the Linux-thing) and they will find a solution they are comfortable with.

 

[ShyGuy]

Me personally, I plan to use the Pandora as a game system that's capable of far more, rather than the other way around. So I don't mind if it doesn't have a package manager. And this UnionFS stuff is just sounding far too complicated for what we need in a game system.

 

[adamorjames]

Me personally, I plan to use the Pandora as a game system that's capable of far more, rather than the other way around. So I don't mind if it doesn't have a package manager. And this UnionFS stuff is just sounding far too complicated for what we need in a game system.

Seeing how big the divide is on the "behind closed doors" decision made, I think both general ideas will be supported.

EDIT: The end. (of course it's not.. just watch sum1 will reply)