Slashdot Mirror

← Back to Stories (view on slashdot.org)

Building A Better Package Manager

Posted by CmdrTaco on from the something-to-think-about dept.

SilentBob4 writes "Adam Doxtater of Mad Penguin has published a preliminary layout for his proposed cross-distribution package manager capable of adding/removing software from any locale. He is suggesting the interface will basically allow for installation of several major package formats including RPM, DEB, TGZ, as well as source code with the ability to pass build time options. All of this will come at the price of standards of course, including naming, documentation, and package structuring. If this idea were to catch on, it would signify a major leap in desktop Linux usability. This might be a project that UserLinux might benefit from. Read the full column here (complete with GUI mockups)."

11 of 431 comments (clear)

  1. Please explain....? by Anonymous Coward · · Score: 5, Interesting

    For a simple Windows user, what are these "packages" and why do they need to be managed?

    What is so special about this? It seems just eliminating the whole concept of packages would make life so much easier. Installation programs (like MSI files) are simpler, aren't they?

    This is not a troll. Please answer my question, don't mod me down.

    1. Re:Please explain....? by IamTheRealMike · · Score: 5, Interesting
      Installation programs (like MSI files) are simpler, aren't they?

      I think once you spent hours disassembling and debugging these "simple" installer programs to make them run on Wine you'd have a different view on the matter ;)

      Let's do a quick review of how things are done on Windows:

      • InstallShield/NSIS type installer programs. These embed all the data needed inside themselves, or in the case of InstallShield the actual installer is wrapped by the equivalent of a WinZip self extractor. Ever wondered why InstallShields take so long to start? Well, the first thing it does is extract a bunch of files (setup.exe, data.cab, some dlls etc) that comprise the installer, then it runs setup.exe which in turn extracts the InstallShield Engine to your local hard disk, possibly upgrading it in the process. Then it runs it and makes RPCs to it using DCOM, which starts the actual installation - done by iKernel.exe.

        This is sort of how autopackage works, except we do it in a much simpler way and don't rely on CORBA (the nearest equivalent of DCOM on Linux). These installers have no dependency management beyond "is this file the right version? No? replace it then" which has caused some truly horrific hacks like Windows File Protection.

      • MSI packages. These are the closest Windows has to traditional RPMs/DEBs. You need to install the runtime support separately for MSIs to work. They are based on a bizarre kind of database, with its own dialect of SQL. MSIs are mostly data but are extendable via COM, iirc. They even deal with dependencies, via MSMs (merge modules).

        Yes, Windows apps have dependencies too. Check out this list to see..

        MSIs "deal" with dependencies by including the least common ones inside themselves, causing huge and bloated downloads, and leaving the user to figure out random breakage for ones that don't exist (how many times have you found that an app assumes the presence of some VB/VC++ runtime lib that just wasn't there?).

        They can get away with this because Windows is a platform and a whole pile of technology is guaranteed to be present. For instance, you know without needing to check that graphics support is available, because it's a part of the kernel and cannot be removed. On the server that's an achilles heel, on the client it's an advantage (in terms of packaging).

      • MSI/InstallShield hybrids. [shudder]. Let's not go there. These things take evil to a new level.

      • Zip files. All MS Windows binaries are relocatable. In contrast, virtually no Linux binaries are. That's partly because it's not at all obvious how to make them so - there is no glibc API available to figure out your absolute path, rather stupidly (and I'm too scared of Uli Drepper to submit one ;). We wrote a simple dropin C file to help C/C++ programs do this - making a program relocatable makes many users lives a lot easier, so do it today.

      Because there is no standard Linux platform (the LSB never caught on), and the user can basically arbitrarily add, remove or upgrade individual components as they see fit (from the kernel to the theme in use) package managers are used to manage and maintain it all. Unfortunately, because there is no standard platform, the distro becomes the platform - of which there are many.

      The freedesktop.org platform effort and the LSB are both worthy steps forward in this area and I hope they pick up steam. In the meantime, approaches like autopackage, being dependency-smart and having communities of packagers are the way forward.

  2. *BSD ports system? by Anonymous Coward · · Score: 5, Interesting

    Why not leverage from the BSD ports system? It already builds directly from source, checksumming the downloads to ensure security, and applies BSD-specific patches. Shouldn't be too difficult to grow this so that source patches and binary packages are platform-neutral.

    ps: BSD trolls are dying!

  3. Re:Don't leave out Gentoo! by The+Night+Watchman · · Score: 4, Interesting

    My main recommendation for Gentoo...

    Let's say I update my portage tree, and then I want to upgrade a package, like GAIM, for instance. GAIM's dependencies are GTK and a bunch of other stuff. When I try to upgrade my version of GAIM and there happens to be a better version of GTK available, Portage will upgrade GTK first, regardless of whether you actually need the very latest GTK to run GAIM. I'd rather see Portage know what the minimum version a dependency has to be in order to get a program running. As far as I know, it'll just upgrade everything in the dep tree.

    Unless I'm mistaken, at least. I've been using Gentoo for a while now, and for the most part I just do a "emerge -u world", which takes care of me pretty nicely. It just takes a while.

    ---

    --
    "Every jumbled pile of person has a thinking part that wonders what the part that isn't thinking isn't thinking of"-TMBG
  4. Re:Don't leave out Gentoo! by revividus · · Score: 5, Interesting
    constant pro-Gentoo advocating on slashdot

    Funny, all I ever see is Gentoo bashing. Are we reading the same sladhdot?

    --

    philcrissman.com.

  5. Re:Again? by pyros · · Score: 5, Interesting
    And yet nothing ever changes.

    Not true. Red Hat's up2date supports apt repositories and the dpkg format is getting GPG signature/hash checking. From discussion late in the Fedora Core 1 beta stage it seemed that there is internal pressue to include apt in the core distro at Red Hat. Those are big changes, I think. I stopped reading the article since it's getting slashdotted, but it the author[s] can implement a single database that tracks installation by RPM, deb, and tgz, then I'd wager those features will be added to RPM and dpkg down the line. I honestly can't see either Debian or RedHat jumping ship to a new system, but they both borrow features from each other, so why not from this too?

  6. FreeBSD ports collection by stan7826 · · Score: 3, Interesting

    Sounds like everyone is looking for something like the FreeBSD ports collection.

  7. Isn't this what alien does? by Timbo · · Score: 3, Interesting

    alien

  8. Is this such a good idea? by Gilesx · · Score: 3, Interesting

    Looking at this from a newbie's point of view, is this really such a great idea? I mean, at face value, the idea of us living in a utopia where all the differing packaging standards are compatible is nice, but how many "green" Linux users would even understand what a difference is? They would see themselves as using Linux as opposed to Windows, and not abc's Linux as opposed to xyz's Linux or Windows...

    Total package compatibility would most likely lead to someone using Red Hat trying to install a debian package, and then getting frustrated, confused and pissed off with the inevitable failure due to the entirely different internals of Debian and Red Hat.

    Unfortunately, it is a sad fact of life that Linux distros are deviating from the once common base they shared. An example of this is Mandrake - I used to use Mandrake around versions 6 and 7 and quite often installed Red Hat rpms successfully. However, as those crazy French spend more time tweaking Mandrake in weird and wonderful ways, it becomes further and further removed from Red Hat. Sure, they both use the .rpm standard, but can you imagine trying to install a Mandrake RPM with a *lot* of deps on a Red Hat system?

    All of this leads me to conclude that perhaps rather than concentrating on unifying packaging, we should instead focus on making incompatible packaging systems for each major distro. IMHO, it would be much easier for a newbie to distinguish between what will and won't work if they were guaranteed that an rpm would ALWAYS work on Red Hat, and some other kind of package (MPM?) would ALWAYS work on Mandrake....

    --
    Sunday you're Thinking Different, Monday you're a huge tool, paying too much and waiting to think like everyone else.
  9. Hear Hear by wowbagger · · Score: 4, Interesting

    What I'd like to see is more distro vendors moving to a metapackaging system like APT, and then the following rule applied throughout:

    Either your package uses packages from some standard repository (Linux standard base, anyone?)

    OR

    You will provide all needed packages that are NOT in that standard set in your APT repository.

    So if I provide Foo.1.2.3, and it requires Narf.2.4.pentium, and the standard repository is providing Narf.2.3, then I must provide Narf.2.4.pentium on my site.

    Of course, I would also pimpslap anybody who actually depended upon Narf.2.4. pentium as opposed to simply Narf.2.4.

    And to address the tweakophillia of the Gentoo types - what about a program that could be run from a cron job that would examine all recently installed packages, pull the source packages, rebuild them with the locally provided options, and upgrade them? Thus, I could *quickly* install Poit.9.1, and then tonight my machine would pull Poit.9.1.src, build it with "-Os -march=athlon-xp -mcpu=athlon-xp -mfpmath=sse,387", and install it.

    --
    www.eFax.com are spammers
  10. Re:Dependancies by IamTheRealMike · · Score: 3, Interesting
    This will lead to problems as the loader will load only ONE version of the library and require both a.out and a.so to use the same version of b.so. This is why rpm's of the same program are not compatible accross different versions of the same distro

    Whoa, slow down. That's not right at all. Firstly, some RPMs are compatible across distributions, but not all - and it's basically hit and miss.

    The linker fixup problems are one issue yes, but to be honest these occur rarely, especially once you start stripping unnecessary DT_NEEDED entries from your binary (unnecessary -lfoo options).

    Eventually we'll need to change it to be more like how Windows does it, but it's not a high priority. Fixing build tools to not dump piles of bogus (in the case of recent toolchains) -lfoo options on the compiler is a more important issue, but I have no idea how to fix this in a general way. Possibly extensions to pkg-config would need to be made, certainly this is something that will require large-scale changes to peoples build systems.

    I'm hoping that when autopackage is released and stable, it'll be so fantastically popular that it will motivate people to fix these myriad binary portability issues in their apps (and none of them are unsolvable or inherent in the way Linux works). We're writing a guidebook to help people do this, but it's not really released yet.