Rethinking PNDs and standard packaging approach


I think the solution to this should be to not have an eMMC, just have the microSD slot, and people have their OS in there. All dependencies would fit if the card is big enough, and if it's not, then they would have to buy a bigger one. The Pyra would ideally come with a 32GB or so one.
 
I think the solution to this should be to not have an eMMC, just have the microSD slot, and people have their OS in there. All dependencies would fit if the card is big enough, and if it's not, then they would have to buy a bigger one. The Pyra would ideally come with a 32GB or so one.
We have the best situation out there, we have the option for both with the current situation.. Performance wise, I like the eMMC solution over uSD..
 
Last edited by a moderator:
Assuming we get an eMMC of 16 GB or larger, that'd be plenty for 99% of users as long as they don't fill it with too much other crap, like cat pictures.
 
as long as they don't fill it with too much other crap, like cat pictures.
6r8v.jpg
 
OK, but if one wants more dependencies, they may have to buy a uSD card then.
Even if we get the lowest planned eMMC size of 8GB, I doubt that for just OS related things we would fill it too quickly. I run my omap5 devboard on an 8GB SD card, on my debian armhf install I have a good set of compiling libraries, languages, python, mono..etc and on top of  that Libreoffice and other utilities and I haven't even used half of it yet.

Hell I barely use 16GBs of the 32GB SSD on my desktop, and that isn't a lightweight install.  I do have separate drives for games and such.. 

Filesystem      Size  Used Avail Use% Mounted on

/dev/sdb3        28G   16G   12G  57% /

/dev/sdb1       142M   65M   70M  48% /boot
 
Last edited by a moderator:
But if java e.g. is preinstalled, but you shall be able to remove it nevertheless, you can't find out the needed packages based on the default system. You have to know every dependency of your application, which may be hard and very trial and bug report for more complex applications.

Furthermore the Pyra will probably compatible to the Pandora. What if I deinstall SDL_Net and a pandora pnd needs it? Shall all pandora pnds have the generic dependency "Everything, which was on the pandora preinstalled"?
 
I still don't think it's a good idea to install debian packages on removable media
It isn't, that was one of the driving factors behind the PND system. If it were easy or practical to install dependencies to removeable media the Pandora would have done it. PNDs were the solution.
 
But if java e.g. is preinstalled, but you shall be able to remove it nevertheless, you can't find out the needed packages based on the default system. You have to know every dependency of your application, which may be hard and very trial and bug report for more complex applications.
It would not be hard to modify the Debian package manager to check the currently visible PNDs and give a warning if you're trying to remove something that is a dependency of one of them.
Furthermore the Pyra will probably compatible to the Pandora. What if I deinstall SDL_Net and a pandora pnd needs it? Shall all pandora pnds have the generic dependency "Everything, which was on the pandora preinstalled"?
Yes, that seems like a reasonable default. If the field is missing, assume it depends on everything in the Pandora default install.
 
I think the Pandora compatability layer will most probably be a separate package anyway (because of the soft/hard float split and generally newer versions like glib, etc.). More like the 32-bit library packages for 64 bit systems.
 
That is actually part of my point. Maybe the new version of the library only gives a minor improvement, say it is 5% faster or fixes some minor glitch. Then the attitude of most package maintainers would be: "meh, it's not worth the effort to update my package and force everyone to re-download it, why fix what is not broken?". But all of these "why fix it if it ain't broken" can add up.
I don't see a problem if these cases add up. What are the downsides? The pnds itself would still work, and if a gain in performance is of interest the maintainer will do the update anyway. The only reason I could think of would be security, but I do not see many cases where there may be an interest in having them released as a pnd while security is not a concern at the same time anyway.
Because I also want preview videos, which could take several dozens or hundreds of megabytes. And because screenshots will have a higher resolution so they will get bigger, maybe several megabytes if you have a dozen of them. SD card space is maybe not an issue, but download size is.
I don't see any connection between videos that aren't included anyway and screenshots. The resolution will be higher, but I don't think that will inflate the size that much. Having a screenshot with the size of several megabytes, is a general problem - this problem would also exist with only one screenshot beeing possible to include.My company had such a problem recently: Our marketing department included a 1,5MB company Logo into every E-Mail Signature, which led to the rather comical result that file sizes of the 2xFullHD screenshots (usually <500kB jpegs) people send us where still a lot smaller (in terms of file size) than the company logo we got with the e-Mail too.

We should probably stop referring to the Pyra's proposed internal storage as "NAND": technically yes, eMMC is NAND flash, but it kind of has a slightly different meaning in this context and can cause confusion.
Very good idea. 
And I don't want to download preview screenshots, especially if there is no easy way to view them. Currently the only way to view anything but the first screenshot on the Pandora is by manually mounting the PND, figuring out where the screenshots are, and viewing them. Any other method does not even use the screenshots from the PND, but re-downloads them from the repo server.
I thought this won't be a problem as the new format would not use the same technique as the current (just "glueing" metadata and the first screenshot and the end of the file) ?
It would not be hard to modify the Debian package manager to check the currently visible PNDs and give a warning if you're trying to remove something that is a dependency of one of them.
I more into leaving everything that is not absolutely necessary to be untouched. Ideally alterations are only made if they are needed to accomodate for the Pyras hardware differences. Otherwise you will increase the amount of maintenance work, without much (or any) benefit to justifiy it.
 
and if a gain in performance is of interest the maintainer will do the update anyway.
I do no think so... We already have abandoned packages, which new maintainers try to improve, which is a mess.
It would not be hard to modify the Debian package manager to check the currently visible PNDs and give a warning if you're trying to remove something that is a dependency of one of them.
I more into leaving everything that is not absolutely necessary to be untouched. Ideally alterations are only made if they are needed to accomodate for the Pyras hardware differences. Otherwise you will increase the amount of maintenance work, without much (or any) benefit to justifiy it.
Using the default Debian way of installing and manages packages for PNDs _is_ a big benefit imho. ;) However I am not sure, whether this would confuse users...
 
and if a gain in performance is of interest the maintainer will do the update anyway.
I do no think so... We already have abandoned packages, which new maintainers try to improve, which is a mess.
Doesn't that cater to my point ? If new maintainers have a hard time on improving the pnd, it is very much likely that a dependency isn't correctly fullfilled anymore. This would happen regardless of wether the lib remains in the system directly or is contained in the pnd. The difference is that you drive up maintence time as for every update on a lib you need to check wether the pnds that rely on it break or not. And if you find some of those, you need to upgrade their binaries too, which makes things even more complicated and time consuming unless you just want to flag these with something like "will only run unless you did not update since %certaindate%" and be done with it.


Recent example: Comix, needed an update due to the move from Python 2.7 to Phyton 2.8 (not 100% sure about the version numbers).

Using the default Debian way of installing and manages packages for PNDs _is_ a big benefit imho. ;)


However I am not sure, whether this would confuse users...
I disagree if it results in something that needs a maintainer as soon as code changes are made somewhere higher "upstream" (outside of the Pyras realm).
 
Last edited by a moderator:
I thought you were disagreeing with yourself until I reread the earlier posts. :D
 
Last edited by a moderator:
Libs should always use a version numbering that make it impossible to break things. That is exactly the point of version numbers. Nothing depends on just "SDL", it depends on either libsdl1.2 or libsdl2.0 -- if a new library version breaks binary compatibility and in particular if its API changes in a non-backwards-compatible way, then the major version number should always be incremented. How do you think the maintainers of distributions do it? Do you really think they just try all stuff out randomly to figure out what keeps working and what doesn't whenever a library gets updated?
 
if a new library version breaks binary compatibility and in particular if its API changes in a non-backwards-compatible way, then the major version number should always be incremented.
If this were always the case we wouldn't have the proverbial "dependency hell" that Linux became infamous for.
 
Libs should always use a version numbering that make it impossible to break things. That is exactly the point of version numbers. Nothing depends on just "SDL", it depends on either libsdl1.2 or libsdl2.0 -- if a new library version breaks binary compatibility and in particular if its API changes in a non-backwards-compatible way, then the major version number should always be incremented. How do you think the maintainers of distributions do it? Do you really think they just try all stuff out randomly to figure out what keeps working and what doesn't whenever a library gets updated?
Try a Qt 4.0 application under Qt 4.8. How you say it is is how it should be, but in many cases isn't. This gets even fuzzier when applications depend on "unintended" functionality within libraries.

EDIT: Assuming a versioning system such as semver. It is somewhat impractical as sometimes stupid design decisions need to be fixed and doesn't warrant a major version bump.
 
Last edited by a moderator:
if a new library version breaks binary compatibility and in particular if its API changes in a non-backwards-compatible way, then the major version number should always be incremented.
If this were always the case we wouldn't have the proverbial "dependency hell" that Linux became infamous for.
Dependency hell is exactly the problem that has been solved by sufficiently smart package managers that can automate the process of recursively installing dependencies.

Libs should always use a version numbering that make it impossible to break things. That is exactly the point of version numbers. Nothing depends on just "SDL", it depends on either libsdl1.2 or libsdl2.0 -- if a new library version breaks binary compatibility and in particular if its API changes in a non-backwards-compatible way, then the major version number should always be incremented. How do you think the maintainers of distributions do it? Do you really think they just try all stuff out randomly to figure out what keeps working and what doesn't whenever a library gets updated?
Try a Qt 4.0 application under Qt 4.8. How you say it is is how it should be, but in many cases isn't. This gets even fuzzier when applications depend on "unintended" functionality within libraries.
If you're relying on undocumented/non-guaranteed functionality of a specific version of a library, you're probably doing something you shouldn't do anyway, but if you insist, then sure, feel free to statically link or include that specific version.

If Qt is using minor version numbers to introduce backwards compatibility breaking changes, then you better specify the dependency sufficiently precisely (i.e. not 4.*.* but 4.0.* or 4.8.* or whatever). It still seems like a better idea to install (potentially different versions of) libqt system-wide than to have to include it in the PND of each and every application that depends on it.
 
Dependency hell is exactly the problem that has been solved by sufficiently smart package managers that can automate the process of recursively installing dependencies
If it can be solved with proper installation ordering then it isn't dependency hell.Dependency hell is installing libfoo1.1, writing an application against that, and then upgrading to libfoo1.2 and finding the application no longer works because the interfaces have changed. Do you keep a copy of libfoo1.1 around? That's how desktops do it, but even at 16GB of internal storage there's still a danger of running out with enough "same but slightly different" libraries. And being able to keep each one separate: if your application just looks for "libfoo" without any nuance to the version (because you assume that upgraded versions won't break compatibility) it doesn't matter what the package manager does, your app will never find the version it needs. You then need to go back and either upgrade to use the new libfoo1.2, or at the least recompile so it looks for a very specific version.

I'm sure the problem is much better now, I remember 10 years ago complaints about having to keep a dozen copies of different libraries as each one was required for binary compatibility, and now it's down to just a few cases, but just because it's better doesn't mean it should be dismissed.
 
Back
Top