The key point of this post is to make you realize why classical package management (apt, rpm) will not function on the Pandora, and why big fat binaries are a solution. Mostly clarified from my previous post. Don't mistake me, I really like the way apt and such do their things, I have just come to realize some of the limitations.
Limestraël said:
Are you familiar with a package manager such as pacman, rpm or apt-get? Because it sorts out all of these issues, it's its function.
Ain't it some way to adapt some existing package manager?
It appears they cannot deal with the Pandora's dependencies at all (hear me out on this one). The key problem here is that software is installed on different media, a combination of inserted SD cards decides how software at any time can depend on one another, and this makes for some confusing stuff. Deciding which dependencies are stored on which (if not on multiple) media is hard to get right if you do not simplify the problem. Also, this is not what those package managers were designed for, they assume a single monolithic filesystem which houses all dependencies at any time, not some scattered form of availability. It would be quite a challange to improve a current package manager to take this into account, and would not have that many advantages either. Another big point is this: if a user decides to take one such SD card and manipulate it (via their cellphone for instance), it would most certainly break function as dependencies cannot be fixed at that time as these operations are done without the use of a package manager. This is unacceptable to most users. Also, storage space on the Pandora is cheap, very cheap in fact. You just have to learn yourself to use SD cards for storage, and stay away from the (way too limited) builtin NAND.
The way to get around this is to store all common dependencies (libraries) on the builtin NAND, but with classical package managers this would grow big too soon, as the repositories are designed to have a LOT of libraries for every package. The builtin NAND is just too small to store all libraries on. The better option is to keep a minimal set of common libraries on the builtin NAND and have packages always include their dependencies on the SD cards. This makes the core set of libaries also fixed, so it can be stored in a compressed FS and other fancy tricks. To make a package easily movable, we include the dependencies in the same archives (PND's) as the packages themselves, so users can easily manipulate it wherever they are.
I know the principle behind this method is not that different from what is typically done in Windows or Mac OSX, but it works. The regular heavily managed (apt, rpm and families) way does not work (at least causes a load of issues) on a device such as the Pandora. The advantage of minimized storage due to library sharing is also pretty much cancelled out by the advantages we could gain from PND compression, which is something that is not possible if we avoid the use of readonly filesystems.
Limestraël said:
Recklessly space-consuming, to my mind. And I remind you that Pandora has a limited space.
It has, in fact, unlimited storage space for central apps due to SD card expansion. Most devices have limited space (albeit in the gigabite range) because "installed" stuff is forcibly stored on a single FS, but the Pandora does not because external storage is essentially the same as internal storage, due to the clever use of unionfs.
