Building A Better Package Manager

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)."

Comments

Please explain....?

[Anonymous Coward]

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.

Re:Please explain....?

[IamTheRealMike]

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.

*BSD ports system?

[Anonymous Coward]

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!

Re:Don't leave out Gentoo!

[The Night Watchman]

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.

---

Re:Don't leave out Gentoo!

[revividus]

constant pro-Gentoo advocating on slashdot

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

Re:Again?

[pyros]

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?

Hear Hear

[wowbagger]

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.