Rethinking PNDs and standard packaging approach

Discussion in 'Pyra OS (Debian GNU/Linux)' started by Wally, Jul 16, 2014.

  1. Silent-Hunter

    Silent-Hunter Hardcore Member

    Joined:
    May 29, 2010
    Messages:
    3,005
    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.
     
    sebt3 likes this.
  2. TrashyMG

    TrashyMG Sarcasm Dispenser Staff Member

    Joined:
    Jan 18, 2010
    Messages:
    10,459
    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: Jul 21, 2014
  3. Silent-Hunter

    Silent-Hunter Hardcore Member

    Joined:
    May 29, 2010
    Messages:
    3,005
    OK, but if one wants more dependencies, they may have to buy a uSD card then.
     
  4. slaeshjag

    slaeshjag ¯\_(ツ)_/¯

    Joined:
    Apr 8, 2010
    Messages:
    2,687
    Location:
    ~Stockholm, Sweden
    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.
     
  5. Cerbera

    Cerbera Ecnes

    Joined:
    Jun 16, 2007
    Messages:
    8,994
    [​IMG]
     
    rygD likes this.
  6. TrashyMG

    TrashyMG Sarcasm Dispenser Staff Member

    Joined:
    Jan 18, 2010
    Messages:
    10,459
    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: Jul 22, 2014
    levi likes this.
  7. Ziz

    Ziz Advanced Member

    Joined:
    Sep 10, 2006
    Messages:
    1,584
    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"?
     
  8. WizardStan

    WizardStan Mega GP Mania

    Joined:
    May 24, 2008
    Messages:
    16,676
    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.
     
    _jr_ likes this.
  9. _wb_

    _wb_ Microbe Staff Member

    Joined:
    Apr 5, 2012
    Messages:
    5,387
    Location:
    Brussels, Belgium
    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.
    Yes, that seems like a reasonable default. If the field is missing, assume it depends on everything in the Pandora default install.
     
  10. _jr_

    _jr_ Advanced Member

    Joined:
    May 5, 2013
    Messages:
    1,170
    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.
     
  11. thatgui

    thatgui Advanced Member

    Joined:
    Apr 2, 2009
    Messages:
    2,901
    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.
    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.

    Very good idea. 
    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) ?
    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.
     
  12. Ziz

    Ziz Advanced Member

    Joined:
    Sep 10, 2006
    Messages:
    1,584
    I do no think so... We already have abandoned packages, which new maintainers try to improve, which is a mess.
    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...
     
  13. thatgui

    thatgui Advanced Member

    Joined:
    Apr 2, 2009
    Messages:
    2,901
    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).

    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: Jul 23, 2014
  14. rygD

    rygD Nihilistic Mystic

    Joined:
    Feb 28, 2014
    Messages:
    7,342
    Location:
    Everywhere
    I thought you were disagreeing with yourself until I reread the earlier posts. :D
     
    Last edited by a moderator: Jul 23, 2014
  15. thatgui

    thatgui Advanced Member

    Joined:
    Apr 2, 2009
    Messages:
    2,901
    If no one is currently available I have to make due :blink: , thanks for the hint
     
  16. _wb_

    _wb_ Microbe Staff Member

    Joined:
    Apr 5, 2012
    Messages:
    5,387
    Location:
    Brussels, Belgium
    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?
     
  17. WizardStan

    WizardStan Mega GP Mania

    Joined:
    May 24, 2008
    Messages:
    16,676
    If this were always the case we wouldn't have the proverbial "dependency hell" that Linux became infamous for.
     
  18. bzar

    bzar A Commando

    Joined:
    Sep 22, 2008
    Messages:
    4,444
    Location:
    Finland
    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: Jul 23, 2014
  19. _wb_

    _wb_ Microbe Staff Member

    Joined:
    Apr 5, 2012
    Messages:
    5,387
    Location:
    Brussels, Belgium
    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 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.
     
  20. WizardStan

    WizardStan Mega GP Mania

    Joined:
    May 24, 2008
    Messages:
    16,676
    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.
     

Share This Page

Loading...