The Pnd Package Manager

Is this something that you would use?

  • Yes, definitely.

    Votes: 84 77.8%
  • Well, I don't know; I'd really need to have the feature that I'm going to specify below.

    Votes: 7 6.5%
  • Nah, the File Archive is enough for my needs.

    Votes: 10 9.3%
  • Yeah, and I'd help improving it.

    Votes: 7 6.5%

  • Total voters
    108

Just a question :
Will you provide some kind of command line interface for your package manager?

By the way, it's a nice work you did! We definitely need this!
Does it already handles properly dependencies?
 
Limestraël said:
Just a question :
Will you provide some kind of command line interface for your package manager?
Well, the name "PND Package Manager" is a little bit misleading. Currently, only the repository part is semi-finished, and that's what has been shown in the screen shots.
We still need to make a program that runs on the Pandora itself.
Limestraël said:
By the way, it's a nice work you did! We definitely need this!
Does it already handles properly dependencies?
PND packages do not have dependencies. You just download one package and that package contains everything you need. It's easier that way.
 
Last edited by a moderator:
dflemstr said:
PND packages do not have dependencies. You just download one package and that package contains everything you need. It's easier that way.

Easier? So when 2 programs need the same lib you install it twice? Although the Pandora has a much more limited space than a PC? That's to me the main purpose of a package manager, dude! It handles dependencies so that it may be easier for the user. I'm not critisizing your work, but I think there's something I missed.

dflemstr said:
Well, the name "PND Package Manager" is a little bit misleading.

Yes, it seems.
 
Last edited by a moderator:
Limestraël said:
Easier? So when 2 programs need the same lib you install it twice? Although the Pandora has a much more limited space than a PC? That's to me the main purpose of a package manager, dude! It handles dependencies so that it may be easier for the user. I'm not critisizing your work, but I think there's something I missed.
Well, how else are you efficiently going to distribute dependencies on media you have no idea of where some of the libraries are going to be?

For example, say I wish to move a package from one place to another, suddenly a lot of other stuff would have to move with it. If a user does this outside of a local package management app, it would break stuff. It is simply not possible to do this without limiting the ease of use of PND packages. The solution: provide each PND with its unique static dependencies. Another advantage is that there are no library conflicts to speak of and every app can use the code it prefers. It also ensures that when people experiment with their OSses and change stuff significantly, at least PND's will work pretty much all the time.

It is not really a replacement to ipkg, which is where the mainstream angstrom stuff will still be distributed for developers who like that at least. For all intents and purposes, PND seems the superior choice for user "big fat app" selection.

Limestraël said:
dflemstr said:
Well, the name "PND Package Manager" is a little bit misleading.
Yes, it seems.
The implementation is more of a PND repository, the only management of packages is done on the server. Name suggestions are welcome :)
 
Last edited by a moderator:
polyroy said:
Well, how else are you efficiently going to distribute dependencies on media you have no idea of where some of the libraries are going to be?

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?

For example, say I wish to move a package from one place to another, suddenly a lot of other stuff would have to move with it.
What about a main PND depository, which would contain the major libraries (libc, SDL for instance)? Or a tracker, which has a list of which depository contains which important package? I don't get it out of nowhere, such things already exist, I don't see why they'd not be appliable on the Pandora, why this would be different. (I had a friend running a Ubuntu on a SD-card with his EEEPC)

Another advantage is that there are no library conflicts to speak of and every app can use the code it prefers.
Recklessly space-consuming, to my mind. And I remind you that Pandora has a limited space.

Unix distributions have been using package managers for a very long time, and that's basically their main asset I think when compared with Windows. Because it ensures the consistency and the fact of being up-to-date of the system, that every program has all it takes to run, and that there will be no duplicates.
 
Last edited by a moderator:
Limestraël said:
Easier? So when 2 programs need the same lib you install it twice? Although the Pandora has a much more limited space than a PC? That's to me the main purpose of a package manager, dude! It handles dependencies so that it may be easier for the user. I'm not critisizing your work, but I think there's something I missed.
This setup encourages the use of standard libraries. Standard libraries are a very good thing. From what I've seen of the software setup, there will be a lot of standard libraries already installed that developers can use.
In the event a developer does decide to use a non-standard library, then you need to do one of two things: include it in the PND file, a single file that the user simply downloads and everything just works; or have it installed to the NAND prior to copying the PND file to the SD card somehow, and heaven help you should you have to reflash the NAND and remember what libraries were previously installed in order to run games that use the non-standard libraries.
Premature optimization is the root of all evil, and in this case you are talking about saving tiny fractions of the space available. SDL is 352K. KILOBYTES! It can fit on a single density 3.5" floppy disk. It is a drop in the ocean on even a 2 gig card. Some libraries may push upwards of a meg or two. We're still talking about non-standard and therefore rare (in theory, because if they were common they'd be made standard) libraries. Maybe you have a dozen copies of various libraries totaling 50 megs of wasted space. That 50 megs of wasted space pales in comparison to the effort (both for user and developers) of keeping their non-standard libraries straight.

edit:
Ahah, I think I see the confusion.

Limestraël said:
What about a main PND depository, which would contain the major libraries (libc, SDL for instance)?
The major libraries are standard and included in NAND, such as libc, SDL, OpenGL,... others. We're only talking about when some developer wants to use weird library QvGX that few people have heard of.

Limestraël said:
Recklessly space-consuming, to my mind. And I remind you that Pandora has a limited space.
Pandora's space is unlimited as games and data can be stored to SD. The NAND (where the libraries would have to be installed) is limited. Therefore you are, in fact, arguing AGAINST a package manager which installs necessary libraries by talking about limited space.
 
Last edited by a moderator:
Well, I must admit I did not see the things this way. (Especially with the NAND stuff)
Whatever, I will see when I get my Pandora. But I still wonder how this will work for simple apps (not games) which usually heavily rely on other libraries' packages on usual Linux distributions. Say (I said 'say'!) I wan't to install The Gimp, well it depends on all the GTK stuff.

Keep up the good work, dflemstr!
 
What most people don't realize is that the Pandora will definitely be running from something like squashfs with LZMA, which will be a read only filesystem that is 1 file but highly compressed with very quick reads. I wouldn't be suprised if updates only just replace that file.

If you want an example of the power of LZMA, download http://7-zip.org and compress a lot of executable files, like in System32 (if you do the whole folder it will take a long time).

If you want a nice example that's already premade, check http://driverpacks.net/driverpacks/latest and see the compressed size versus the real size. Just hit the View button and browse, and it will tell you both. Check especially the Graphics and the WLAN (wireless cards).

DriverPack WLAN 8.06 for Windows 2000/XP/2003 (x86):

File details

File size
20.1 MB (21,077,373 bytes)
Original size
158.91 MB (166,627,131 bytes)
Compression ratio
7.91:1
 
Guys, this has been discussed ad infinitum. I was also totally against the PND system when it was first presented by ED, but now I've learned to accept it. I would REALLY have preferred to use IPKG or some other system, like DEB (Which is what I will do after I have installed Ubuntu on an SD card, which is possible by the way) but this is the best thing we can get under the circumstances.
 
Limestraël said:
well it depends on all the GTK stuff.
GTK is a pretty standard library. I'd be very surprised if it wasn't pre-installed to the NAND.
In fact, we've already seen ED in a video playing with GIMP, so I'd be even more surprised if it wasn't installed.
 
Last edited by a moderator:
WizardStan said:
Limestraël said:
well it depends on all the GTK stuff.
GTK is a pretty standard library. I'd be very surprised if it wasn't pre-installed to the NAND.
In fact, we've already seen ED in a video playing with GIMP, so I'd be even more surprised if it wasn't installed.

Yes but, GTK is a heavy one. I do agree that compression enables to save much space, but you'd have to de-compress it each time you need it, and this is not time saving.
What it we also need Qt?

By the way, I didn't find the piece of information: where is installed the Angstrom on the Pandora?
 
Last edited by a moderator:
It's installed on the built-in NAND flash. (Although it is my understanding that some folks with prototype units are instead booting it from SD Cards.)
 
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.
 
Last edited by a moderator:
Prometheus said:
It's installed on the built-in NAND flash. (Although it is my understanding that some folks with prototype units are instead booting it from SD Cards.)

Ok! Before entering this thread I was wondering what would be the use of the NAND. Seems so obvious now that I feel stupid.
 
Last edited by a moderator:
polyroy said:
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.

I understand your point, polyroy, and I stand corrected.
However, I don't think that every pandora user will handle a hundred SD cards with it. For my part, I will use a single 8GB card for apps/games in the first slot, and a big capacity card for data (mostly audio/video), or even use the host USB port to connect a lightweight external hard drive (I hope Pandora can power it, by the way...).

How will happen the update of the system, the standard libs, in brief what is in the NAND? There is ipkg, but what if an app depends on a older version of a standard app than that of the NAND?
 
Last edited by a moderator:
Limestraël said:
How will happen the update of the system, the standard libs, in brief what is in the NAND? There is ipkg, but what if an app depends on a older version of a standard app than that of the NAND?
Any updates will probably be all-inclusive, a complete new version of the "firmware". It is possible to run the firmware off of SD card too, so you do not need to use the builtin NAND at all. The builtin NAND could simply be seen as a permanently inserted SD card. The firmware is probably stored in a readonly filesystem, making it immutable. You can pretty much choose whatever you will store in the NAND, it is not like this is required. If you take an SD card which you leave permanently inserted, this could replace your NAND completely. This is also the big advantage of having two SD card slots.

If an app depends on specific versions of libraries which are not in standard firmware, it will probably include its own inside the package it comes shipped with (the PND), or be statically linked with it. I see no other solution. The "firmware" should remain static for compatibility and have a single version number for the entire collection. Manipulating the standard firmware is not recommended due to introduction of compatibility issues. PND compatibility is then expressed as a comparison with the firmware version number, nothing else.

If the user wishes to manipulate the firmware anyway, the best way to do this would be to make a new writable FS and map this over the firmware using UnionFS, and then every change you make to the readonly firmware will be recorded in the readwrite filesystem instead, supplementing the information on the firmware. Using IPKG will not modify the firmware itself, but record changes seperately. Whenever you install a new all-inclusive firmware, your old changes would partially map over the new firmware and the unchanged stuff will be updated. This leaves a way to experiment with OS stuff from Angstrom for those that do not like the lack of customization in readonly filesystems.
 
Last edited by a moderator:
polyroy said:
PND compatibility is then expressed as a comparison with the firmware version number, nothing else.

Fair enough.

If the user wishes to manipulate the firmware anyway, the best way to do this would be to make a new writable FS and map this over the firmware using UnionFS, and then every change you make to the readonly firmware will be recorded in the readwrite filesystem instead, supplementing the information on the firmware. Using IPKG will not modify the firmware itself, but record changes seperately. Whenever you install a new all-inclusive firmware, your old changes would partially map over the new firmware and the unchanged stuff will be updated. This leaves a way to experiment with OS stuff from Angstrom for those that do not like the lack of customization in readonly filesystems.

Gotcha point!
So UnionFS seems to be the key. OMG, I wish there'll be a good user's manual shipping with the device! (Or at least some tutos on the website) :)
 
Last edited by a moderator:
Limestraël said:
Gotcha point!
So UnionFS seems to be the key. OMG, I wish there'll be a good user's manual shipping with the device! (Or at least some tutos on the website) :)
Remember: this is Linux. Google is your tutorial :p
 
Last edited by a moderator:
dflemstr said:
Limestraël said:
Gotcha point!
So UnionFS seems to be the key. OMG, I wish there'll be a good user's manual shipping with the device! (Or at least some tutos on the website) :)
Remember: this is Linux. Google is your tutorial :p

I completely disagree. With people thinking this way it's no wonder why casual people is still having prejudices like 'Linux is much harder than Windows to use'.
One day, I started using Ubuntu with a very good PDF and it totally changed my mind. After a few days, I realized that Windows was harder to use.

If you keep thinking like that then Pandora will never attract 'normal' people, and they'll simply keep on saying 'PSP/NDS is cheaper and easier to use than this Pandora. I keep my PSP/NDS'. I don't talk about hacking, I talk about normal use. Pandora is not a casual pocket console, so it's 'normal use' goes beyond simple gaming.
 
Last edited by a moderator:
Limestraël said:
dflemstr said:
Limestraël said:
Gotcha point!
So UnionFS seems to be the key. OMG, I wish there'll be a good user's manual shipping with the device! (Or at least some tutos on the website) :)
Remember: this is Linux. Google is your tutorial :p

I completely disagree. With people thinking this way it's no wonder why casual people is still having prejudices like 'Linux is much harder than Windows to use'.
One day, I started using Ubuntu with a very good PDF and it totally changed my mind. After a few days, I realized that Windows was harder to use.

If you keep thinking like that then Pandora will never attract 'normal' people, and they'll simply keep on saying 'PSP/NDS is cheaper and easier to use than this Pandora. I keep my PSP/NDS'. I don't talk about hacking, I talk about normal use. Pandora is not a casual pocket console, so it's 'normal use' goes beyond simple gaming.
Now don't get me wrong. What I meant was that since Linux is an open system, there already are billions of tutorials out there. Even if we were to write a tutorial for the Pandora, there'd still be loads of others that are far superior to it. The best thing we could do would be to copy some other solid tutorial to the Wiki if there really is the need for one.
 
Last edited by a moderator:
Back
Top