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

Autopackage?

[Deraj DeZine]

So this is a similar effort to Autopackage except that it plans on using the native package formats? Intriguing...

Re:Autopackage?

[pubjames]

So this is a similar effort to Autopackage except that it plans on using the native package formats?

Except that this guy has just stated the idea and made a couple of mock-up screenshots, whereas the autopackage guys are coming up with a complete, sensible solution and are leaving the interface until the end.

Re:Autopackage?

[IamTheRealMike]

By the way, it's funny this should be mentioned now but autopackage.org is in the middle of a DNS repropogation - it was switched to point to sunsite.dk literally hours ago.

For now, if it doesn't work, use autopackage.sunsite.dk and bear with us as we fixup the broken links etc.

Mnyah!

[American AC in Paris]

Bah, you kids, always inventing your own names for things!

When I was your age, we called 'em by their proper name--athletic supporters!

"Package manager", indeed...

Again?

[avalys]

This topic comes up how often? Like twice a year?

And yet nothing ever changes.

Re:Again?

[Deraj DeZine]

What are you talking about? These mockups are clearly slightly different from past years! Perhaps no code has been written, but everyone knows that impressive mockups are the key to building successful open source software with your newly-created SourceForget account.

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?

Re:Again?

[Hard_Code]

Because any time anybody (like me) points out that the tradional "unix" file system with /usr and .../bin/... and .../sbin/... and ../local/.., etc. etc. etc., is vestigial and retarded, everybody flames back: U R n0t a rEEL hax0r d00d, with a thousand apologies about why that has to be to compensate for some stupid clustering strategy cooked up in the early eighties (don't know about you, but it seems obvious to me that all configurations for all my applications go in /etc/, while the cryptic /usr/local/sbin is translated into "user-level administrative applications deployed for the local network of this machine". Boy that taxonomy is USEFUL!).

The nearest thing I can find to a decent package manager is 'stow' which essentially does *nothing* but hide all that hierarchical complexity behind top-level directories. A new package *format* is not the problem, it's layout and management that is the problem. Everything else is a new wrapper on the same old problem.

it's not the package format

[ajagci]

People get so hung up on the package format. It really isn't about the package format, it's about the people and organization behind the packages and whether they produce a consistent distribution. A "better" package format or a better installer isn't going to help you when a piece of software expects libraries to be there that just aren't available, or when an install script assumes functionality you don't have.

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....?

[cca93014]

A package is basically the same thing as a Windows MSI file.

The problem is that different distros have different directory layouts, configuration file layouts, different places to put binary files, different ways of updating the internal library database etc. etc. etc.

The problem is basically a manifestation of there being more than 1 distro of linux and having distro maintainers who have not agreed on a common standard for this stuff. It's Linux's major achilles heal IMHO.

Re:Please explain....?

[zapp]

Packages *are* the installers (like MSIs)... only each distribution of linux supports a different one (well, some of them support the same formats).

In windows, "Add/Remove Programs" is the "Package Manager". Think back to Windows 3.11 where if you installed a program and you wanted to remove it, you had to delete the directory, find any files it dropped in c:\windows, delete them, edit your autoexec.bat, config.sys files... etc.

Since there is no uniform package manager for linux, and a lot of stuff is just distributed as source (ie: NO package manager support, you're back to the plane old file drop method in win3.11), it can be kind of frustrating.

For example: Redhat, Mandrake, Suse (and others) all use RPM.
Debian uses DEB files
Slackware uses .tgz files
And anything can usually be found in source format, typically with the extension .tar.gz or .tar.bz2

It's rather sad when you're on Redhat, and you find a package and its either only in DEB format, or it's in SuSE RPM (which has different dependancies than redhat, so you might not be able to use it) or ... (you get the idea, it's a pain).

So the point is, we need something equivalent to "Add/Remove Programs" that just *works* on all linux distros.

Re:Please explain....?

[Alan Hicks]

So the point is, we need something equivalent to "Add/Remove Programs" that just *works* on all linux distros.

So what's wrong with this old song and dance?

./configure &&
make &&
make install

Other than taking awhile to compile the occasional large program, it's always worked for me. As far as making a desktop linux for dummies, the idea shouldn't be to have some magic whiz-bang tool that does everything and works on every platform and.... you get the picture. If there is a massive desire to use linux from people who are not competent enough to compile their own packages from source, then major distributions like Mandrake and SuSE will likely offer their own upgrade RPMs or DEBs or what-have-you for download.

Re:Please explain....?

[theantix]

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

With many windows programs, the source is closed and the developer creates a binary package and controls how the program will be distributed. But with free software, many people take those source files and distribute them in whatever way works best for them -- a package is simply a way to put programs in a file for distributing to others.

If you'd like you can think of of package as an installation program -- with modern end-user distributions the distinction is minor. A package is RedHat, Mandrake, and SuSE all have programs that will automatically install a .RPM package with a GUI front end, not unlike what you would find in a .MSI file in windows -- even more simple, to be honest.

But it gets more complicated than that, because of the increased complexity of the *NIX world. Certain programs depend on external libraries (think of it like a .dll file) to run properly, so the package knows which libraries are required for it to install. Debian, Gentoo, and FreeBSD have great systems for automatically installing those dependancies when the user requests a package, and the .RPM-based linux distibutions are getting better at this too.

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?

Some applications, like the Sun Java JRE, OpenOffice, and the binary NVIDIA drivers (I'm sure there are many others) have their own installation programs. It's ugly and messy and doesn't work that well compared with how each distribution handles packages natively.

To put it more practical terms, if I download OpenOffice from openoffice.org and run their installer I see a custom installation program that they have developed. I have to answer a lot of questions about how my Linux distribution is set up and do this all in an unfamiliar environment. However if I install OpenOffice .RPMs or use Debian/Gentoo to install the program, the package management system knows how to handle many of the default questions, installs everything in an expected place, and presents any questions in a familliar manner.

I hope this helps answer your question.

Re:Please explain....?

[aardvarkjoe]

When we come up with an elegant solution that is cross-distro...

There are already lots of them. .deb, .rpm, and others. The problem is that most geeks (at least the ones in charge) are stubborn idiots. If they said that debian packages are better than rpms five years ago because the only distro they ever used was debian, there's no way in hell that they will ever admit that another package management system could do the job, and agree to standardize.

There's no technical reason why we can't get some people together to iron out the last differences and either create a standard package manager, or create well-defined interfaces that allow any front end to access any kind of package. However, if you did that, nobody would use it anyway.

Re:Please explain....?

[brett_sinclair]

OK, I'll bite...

Packages in typical Linux distributions pretty much do the same things as MSI files on Windows, except that they do much more.

1. They describe how to build from source. That is (obviously) a big deal on an open source platform, since it makes builds repeatable, and so not depending on the magical build environment of one company or person.

2. They deal with dependencies: package "foo" can dictate that it needs package "bar" to work correctly, and that it needs package "foobar" version 2.32 or higher to build. This is a Good Thing, as you don't have to find out what the dependencies are the hard way.

This causes some problems from time to time, since distribution X may not have package "foobar", but the real problem here is that distributions are different. This may also be seen as a good thing: package management is a way to deal with diversity.

3. Standardised package management in a distribution makes other Good Things possible, such as automatic installations of all dependent packages, or automatic upgrades, thanks to tools like apt and yum and the dependency information in packages. That means that you can make sure that every program on the system is up-to-date with just one command.

Another really Good Thing is that package managers allow a lot more control over installations: they know which files are installed by which packages. That makes it possible to check, say, /usr/lib for any shared libraries that are no longer in use, or if any files have been altered. Thanks to dependency handling, it is also safe to remove unneeded old stuff (i.e. you don't have to put up with a gazillion old .dlls in c:/WINDOWS/SYSTEM32).

Re:Please explain....?

[pyros]

So what's wrong with this old song and dance? ./configure && make && make install

No easy dependency tracking, no easy uninstall, no easy upgrade, no audit trail. On a server you don't usually want a compiler installed as it can be a security risk. It's really nice having a database of all the software installed, what versions of what other software it depends on, and reliable way to remove it without keeping the build tree around assuming the build system used has an uninstall method. The only way I would feel confident about not accumulating cruft due to upgrading big packages from source (gnome, kde, X) is if they are installed 100% into a single folder (like /opt/kde/3.2/(bin|lib|conf|man|...). Then I can safely uninstall by deleting that top version folder. Even then, I don't want to take the time downloading and compiling the source, I don't find it to be very recreational. I'd rather run `apt-get install kde` or `apt-get upgrade kde` or `apt-get remove kde`. With that remove command, it also removes packages kde depended on but nothing else does. You don't get that with source installations, you have to keep track of it yourself.

In the long run, unless you are meticulous about tracking which packages need which other packages, and where they were all installed, you are insuring you will have to rebuild your system from scratch at one point. Package managers like APT and Yum, and even up2date allow you to avoid this.

Re:Please explain....?

[brett_sinclair]

only each distribution of linux supports a different one

The real problem isn't package formats (as your example with Suse and RedHat shows).

It's simply that distributions are different. Pretty much any non-trivial Linux program needs a lot of libraries that are non-standard (as in: not in the LSB). Different distributions make different choices, which is probably a good thing, but it breaks binary compatibility between distributions. This has (pretty much) nothing to do with package formats.

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.

Re:Please explain....?

[Clockwurk]

I suggest a pro/con comparison of each.

*Windows*
Pros
+ Install is double-click, then run through the options for install (directory to be used, full or partial install (games and such).

+ Library files are either included with windows or are installed by the program, libraries are placed in the install directory, or are placed in windows/system32. Registry entries are entered by the program, as well as menu shorcuts and/or desktop icons.

+ All packaging is handled by the programmer, from the users standpoint, all installers function the same.

+ Anything, including drivers can be installed from a gui installer, installing video drivers does not require exiting to a CLI.

+ For most programs there is only one version, compatible across all Windows versions (occasionally, there will be a version for the 9x family and one for the NT family.) Drivers and such are for each version. Some will specify which service packs must be installed.

+ Program's files are contained in their directory in "Program files". There is one main location for installed programs (easy to find)

+ Even programs that do not use a .msi installer may be uninstalled through the add/remove control panel.

+ I never have to deal with dependencies, ever.

Cons

- No central repository for updated versions of software. User must download patches or new versions from the software author, or a third party. Some software provides it's own update mechanism.

- Poorly coded uninstallers may leave behind libraries or files/folders and registry entries.

- Binaries may be larger than needed since they must include all libraries not included with windows. (somehow, firefox is a smaller download for windows than it is for linux).

- Some programs may require a reboot after installation. Some windows updates require a reboot.

Neutral

= No CLI installation or uninstallation of programs.

= Multiple installers exist (installshield, cab self extractors, nullsoft installer, sfx archives, etc.). All of these are executables that function approximately the same from the users point of view.

= All updates to windows components are handled through windows update.

= Newer programs may save user files (profiles, saved games, etc.) in a folder in My Documents. Microsoft is said to be pushing centralization of saved files to the "My documents" folder. For example, image files are saved to "My Pictures" by default, and new saved games will be saved under "My Games".

I'd really be interested to hear what you think the pro's and cons are with the current linux methodology. I guess I'm having trouble understanding why the ease I experience with windows programs would somehow be unfit for Linux.

And no mention of encryption

[Anonymous Coward]

I am sick and tired of poorly planned package management. What we need is a system where 3rd parties can build binaries from the same source as the original vendor and get the same exact binary. Then using PGP, we can verify the authenticity of the packages. There is no reason the encryption can't be hidden away and transparent to the end user - checking for signatures of the original vendor only, and wide open for enhancements by power users who want to check multiple sources etc.

Lets do this from the beginning rather than slapping it on later.

OpenPKG

[chipster]

http://www.openpkg.org/

Why reinvent the wheel?

[El Cubano]

APT already handles debs and rpms. tgzs should not be a far stretch. The problem is establishing standards and getting everyone to follow them. For example, all debs in the Debian archive follow the Debian packaging standard, else they would not be accepted into the archive.

Naturally, third parties are free to create their own non-conformant debs. This is just the same as someone creating an rpm for RH9, but it not conforming to the conventions used by Red Hat.

I assert that the tools already exist. I.e., we don't need a new one. The emphasis needs to be on getting people to follow the standards, and possibly creaitng a cross-dsitro standard fo everyone to follow.

Well then build it...

[codepunk]

All smoke and no fire... Don't talk about it just build it. Personally I think someone should sit down and hack together a install package builder program based on something like gdialog and python that outputs a executable compressed image into a single bin file.

A good installer is not hard to accomplish if the desire for it really exists. It is however one of the most overlooked things as open source programs are involved.

Don't make me go hunting down 20 dependency packages but offer to install them for me. A simple script based on wget can do that...

Unifying the Packages

[derphilipp]

Yeah !
Unify those packages.
I am so often confused the RedHat comes in a red box and SuSE in a green one. - Which of those should I buy ?
And Fedora comes with a box you have to fold yourself...

Oh you mean these packages....
(Fedora Linux is included in the RedHat magazine - which has a foldable page for creating a suitable box)

*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!

0Install

[Sanity]

What about 0-Install? It is simple, elegant, doesn't require root to do an installation, seamlessly downloads libraries and other dependancies as they are needed, and integrates nicely into the filesystem. I really think 0Install could be the future of installers, if only they can get someone to build a distro around it.

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!

[bee-yotch]

Ebuild's aren't written in python, they're simple bash scripts. Portage, the system that manages the ebuilds, is written in python, as are eclasses.

I don't really see a point to including ebuild's in this package manager though, as the package manager should already be doing the work of the ebuilds maintain source packages.

Besides, portage will kick this package managers ass anyday. :-)

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?

FreeBSD ports collection

[stan7826]

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

Re:FreeBSD ports collection

[gtrubetskoy]

Some say that there's no need to compile the ports, and they should be all binary, but oh well. There are benefits to binary-package installation.

Don't confuse the FreeBSD ports with a packaging system. FreeBSD has its own nice packaging system. (If you've used Solaris a lot you'll feel right at home) The FreeBSD ports all create and install packages for you "behind the scenes", and you can install any package as binary on FreeBSD as simply as:

# pkg_add ftp://ftp2.freebsd.org/pub/FreeBSD/releases/i386/5 .2-RELEASE/packages/archivers/rpm-3.0.6_8.tbz

Re:FreeBSD ports collection

[pyros]

I will however say that in my experience RPM's are a poorly implemented packaging system. I'm sure plenty will mod me as a Troll or Flamebait, and other's who've never used a linux outside of RH or MDK will pipe up extolling the beneifts of RPMs and i'm just a stupid, lazy fsck, blah blah.....

I'm not going to call you a troll. But I am going to assume you dislike the RPM format due to the dependency-hell problems of the past, if that's not why you dislike it, then feel free to ignore the rest of my post, except the PS. The problem is that many distro maintainers selected the RPM format (Red Hat, Mandrake, Suse, Ark, even the LSB chose RPM as the standard format), and then packaged software with conflicting package names and file system layouts. So you go looking for an RPM for Red Hat, and find one from Suse, and it says it needs xfree86 3.0.3, even though you have XFree86 3.0.3 installed. Or perhaps it needs some particular .so to be in /usr/lib but the Red Hat package owning that file put it in /usr/lib/ssl.

These aren't flaws in the RPM format, these are the problems this project aims to fix. You would see the same problem with dpkg if there were as many popular distributions which used dpkg but didn't base themselves off of debian's repositories.

The other complaint commonly made is that apt is better. Apt needs a tool like rpm or dpkg behind to actually be useful. Apt is purely that part of the system that locates dependencies, like the part of portage that knows to build and install X before building and installing GNOME. It doesn't actually install the package or maintain the database of installed software. Apt also runs very nicely on RedHat. Connectiva and Ark use it as the default system. Mandrake and Suse implement their own dependency tracking system.

PS - In addition to Red Hat and Mandrake, I've also tried FreeBSD (years ago, didn't support all the hardware needed to install), Debian, Suse, Ark, and Slackware.

Re:Don't leave out Gentoo!

[Valar]

This reminds me of something I read the other day in the gentoo forums: Installing Portage on Other Distros

So Yesterday....

[Hornsby]

Don't they know that it's MozillaFirefox and not MozillaFirebird. This installer obviously isn't going to be able to keep up to date.

Learn from Apple

[Octos]

Maybe Apple can do this because they have a standardized directory structure, but what can be easier than dragging an app package to the Applications folder? Poof, it's installed. Don't like it? Delete it. If it's more complex, there's an installer program. Playing with dependencies and makefiles is the reason I gave up on Linux.

Re:Learn from Apple

[TheRaven64]

Umm, proprietary? The .app framework specification is documented, and is based on the OPENSTEP bundle specification supported by GNUStep. You can even put binaries for multiple CPU and OS combinations in the same .app, so you just need to create a single bundle and can run it on any supported platform.

Re:Learn from Apple

[kinnell]

Maybe Apple can do this because they have a standardized directory structure, but what can be easier than dragging an app package to the Applications folder?

The Apple way rocks, the directory structure doesn't matter: you can execute any properly written application from anywhere. There are 2 problems with this in linux. Firstly, most applications are written with full path names in the code for files they reference. Secondly, linux applications are built around a wide range of supporting libraries, few of which are standard to all distributions - this means either huge packages, or a dependency resolution mechanism, like apt.

A linux distribution which wanted to do this would have to firstly pick a core set of standard libraries, then port all the applications they wanted to support.

Re:Learn from Apple

[IamTheRealMike]

Maybe Apple can do this because they have a standardized directory structure

Nope, they can do it because they have a standardised platform. All MacOS X apps have at least one implicit dependency - on some version of MacOS. That one dependency is very easy (well, assuming you are rich) to satisfy, but it gives you a whole pile of functionality.

Because desktop Linux is evolving at such a rapid rate, and because nobody controls it, and because people like being able to control what's on their system to a fine degree, we have no such platform currently.

Unfortunately the first attempts at such a platform foundered when KDE made the bum choice of using a toolkit with a problematic license, so Gnome was started in reaction and now we have two, with neither being widely spread. The Gnome guys are busy moving infrastructure out into non-Gnome libraries like GTK, Cairo, DBUS etc that are explicitly designed to be acceptable to everybody, but unfortunately the KDE guys are still having big internal arguments about whether freedesktop.org (the new attempt) is "forcing" things upon them (see the discussions at kdedevelopers.org)

This is unfortunate because a standard platform that you could depend upon with only one dependency would go a long way towards making software on Linux easier to install.

Isn't this what alien does?

[Timbo]

alien

Good theory, poor practice

[arrianus]

The theory is fine. The problem is that package managers are, in many ways, incompatible. Debian packages, for instance, track dependencies based on the names of other Debian packages (libfoobaz-dev requires libfoobaz). I've seen package management systems that have dependencies based on files (libfoobaz-dev requires /usr/lib/libfoobaz.so). The former system won't recognize dependencies from packages installed in the latter format. Worse, the packages don't overlap. One distribution will have libgnome, whereas another will have 50 different packages, one for each of the Gnome libraries. The problem of dependencies there breaks almost completely.

There's also a matter of versions and security updates. On Debian, I run 'apt-get update; apt-get upgrade' and have a new version. Since the packages are all maintained by the Debian project (and a few smaller projects that target Debian), this works. Versions aren't linear -- Debian back-ports security fixes. The package manager has no way of knowing whether kernel-2.4.24 is newer than kernel-2.4.19-with-patches.

Basically, there is no clean way to install .rpm packages on a .deb system, or vica-versa, without breaking something. It is possible to install packages of one sort on the other system, but eventually, things will break. Each package management system relies on some set of information about packages to work, and each system has a different set of information it provides and needs.

There is room for improvement in package management -- a really good GUI for finding and installing packages would be nice. I wouldn't mind having more information about the packages I'm about to install -- links to project web pages, ability to browse installed files (the packages.debian.org/freshmeat.net/etc. databases either installed locally or quickly accessable from the system), the ability to view screenshots of GUI programs, etc. There's a lot of metainformation that could be added, and better search functionality that could be implemented.

At the same time, on the package build side, it'd be pretty simple to have a system where you make a configuration file of information about the package, and it builds .deb, .rpm, .tgz, etc. packages, and give easy-to-read information about what systems it'll work on. I've heard of tools similar to this, but I haven't seen them used. Adding something like this to the standard autoconf/automake/... process would certainly be nice.

The last solution is to have the groups work together to make sure all packages have the same set of metainformation (more than is needed for any given package system), so that cross-platform package installs become possible. In practice, I don't see this scaling across versions, as package management systems evolve.

One more thing to bear in mind is the perspective of the author of the article -- he says he runs Slackware, and builds most packages from source (something I've stopped doing maybe 3-5 years ago). Slackware's package management tools are very basic, manual, and crude. That gives a very different attitude towards package management than someone running a distribution like Red Hat, which has a much heavier-weight, more technologically-advanced, but somewhat fragile, somewhat inflexible package management system, or a user of Debian, which has a state-of-the-art ubermaintainable, uberupgradeable package management system, but that primarily relies on grabbing packages from one (or a small number) of sources. I apologize about the stereotypes in this paragraph -- they're not entirely true, but the package management systems differ a lot (more than most people realize, if you've ever tried to build the packages), and I'm just trying to make people aware that users of each of them will have a very different world view, and it's important to keep that in mind when reading these articles.

Re:Don't leave out Gentoo!

[polin8]

"emerge -u gaim" will upgrade its immediate dependencies.

"emerge gaim" will just upgrade to the needed packages, or only gaim.

Re:This is Tuesday, isn't it?

[Deraj DeZine]

I have to "manage" my package several times a day!!!

Did you even READ the name of the project I referenced? It's called Autopackage. It takes care of that for you.

Re:Don't leave out Gentoo!

[daserver]

That is because you use the -u flag. If you leave that out it will only update gaim or whatever you were updating.

Re:Don't leave out Gentoo!

[BigJimSlade]

"emerge -u gaim" will upgrade its immediate dependencies.

"emerge gaim" will just upgrade to the needed packages, or only gaim.

Mod up parent please! I don't have any mod points and this concisely explains how portage works.

Re:Don't leave out Gentoo!

[Jerf]

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.

Basically, this is wrong. Sorry. ;-)

The "-u" parameter to emerge will make it work as you described. However, if you just typed "emerge gaim", it would only emerge the minimum required. You have to ask for the "emerge all depencies, too" behavior.

I quite frequently emerge -up world, then just pick and choose what I want updated.

(I just checked "emerge -p world" against "emerge -up world", and "emerge -up" did significantly more packages on my system, where over 100 packages can be updated. On Gentoo, IIRC, the "world" is the list of things that you explicitly emerged; "emerge mozilla" will put mozilla in the "world" list but not any of its dependencies. So "emerge world" can update the packages you cared enough about to explicitly ask for them, and -u will add all possible dependency update.)

I've got a much better idea.

[Doktor Memory]

Let's see if we can actually go for six months without somebody announcing Yet Another Binary Package Management System or Meta-System. That would actually be newsworthy.

The amount of time and money that's been wasted on this problem for over twenty years in the unix world is just mind-boggling. We really do not need to reinvent this wheel again.

KDE + Gnome

[G3ckoG33k]

Yes, I know, this might be considered offtopic, but...

If we get KDE and Gnome work together, then we might also, eventually get an installer too!!! :)

PLEASE!!!

Let KDE 4.0 and Gnome 3.0 be the same!!!

A few things:

[Wordsmith]

Why hasn't anyone developed a system that, from the End-user perspective, works similarly to MSI installations (which work very well). Point, click, next next next. In principal, DEBS/RPMs work similarly to MSIs, but the installation isn't as obvious a procedure to end-users.

And for that matter, why not make the installer intelligent about the distro? Use a single package/installer, but that includes all sorts of scripting information about installation in variosu circumstances. The installer checks to see if it's on RH9, and if so it puts files where RH9 expects them, editing any configurations and making RPM database entries as necessary. If it's on Debian, it takes the appropriate measures there. And so forth.

Why do we see such absurd dependencies that don't seem to happen in the windows and mac worlds? Install a new version of a KDE app, and you need the latest minor revision to the core KDE libs, which in turn requires a minor upgrade to the font server, etc. In the windows world, occasionally you need to update something big like DirectX to install a latest-and-greatest app, but even then the dependencies are often packaged with the app itself. Why isn't this practice more common in Linux/Unix (not counting Mac OS X)? I undestand that many of these apps are under CONSTANT quick-release development and are often tied to bleeding-edge versions of their libs, but why aren't major releases at least more dependency-friendly? Installing an app can be a real pain in the ass even with something like apt, if you don't have the dependencies in the repositories you've defined. And adding new respositories isn't exacly grandma-friendly.

Re:A few things:

[MobyDisk]

Why hasn't anyone developed a system that, from the End-user perspective, works similarly to MSI installations (which work very well)... In principal, DEBS/RPMs work similarly to MSIs...

MSIs are fundamentally different than packages, although they aim for the same purpose.

First, MSIs typically run executable code and/or scripts to perform the installs. But packages usually contain just a list of files and locations, with no scripting required. This is important since a security-concious administrator won't want to run an MSI-like package since nothing stops it from doing rm -rf /. It alsmo makes them easier to create and maintain. Technically, an RPM or DEB can run scripts, but it is uncommon, and you can easily tear them apart and see the script they are running with a few simple commands.

Second, MSIs don't have a central database where all the file information is stored. There is some use of the registry for this, but it isn't quite as good. With RPM/DEB, I can ask the package manager: "What package does /usr/libfoobar.so.1.2.3" belong too?" and "What versions of /usr/libfoobar.so are installed and where?" These are just a few simple examples, lots more can be done.

As far as the granny meter, I rate APT distributions as easier than MSI, because most MSIs display between 3 and 10 screens where you must click "Next" or scroll down and click "I agree." As a consultant to many such peoples, I have been amazed that, many of them cannot get through these installs! An RPM/DEB install with APT handling dependencies does not have any prompts - you just click it, the progress bar goes by, and it is done!

Why do we see such absurd dependencies that don't seem to happen in the windows and mac worlds?

Fundamentally, Linux packages don't have the dependency conflicts that Windows packages have. Windows packages commonly overwrite shared files all the time. By splitting the dependencies into separate packages, that DLL-hell should go away: nobody will overwrite another package's files. But instead, we get it in another form because dependencies aren't stated properly in the packages. I just hope that things will improve over time.

Dead on bro. Remember when Microsoft added "self-healing" to Windows XP because so many companies were making crap installs? Deleting dlls, installing dups, putting them in wrong directories. This is the exact same problem as Windows has/had, but in RPM & DEB form rather than EXE & MSI form. It seems like coders just don't get package management well. And if you look at APT, it even has a healing-like feature now!

Standards

[Milo Fungus]

All of this will come at the price of standards of course...

Standards are not a price, they are an investment. I use standard XHTML, CSS, and SVG in my web design because I care about the future of the web. Besides, if a standard is well-designed (like W3C recommendations tend to be), it actually makes development and maintenance easier. Anyone who has migrated from HTML 3 (or some nonstandard IE/Netscape HackML) to HTML 4 or XHTML with CSS knows what a pleasure it is to work with modern hypertext (and probably also has an abiding and bitter hatred for IE). The same could be true of package installation in Linux if the standard is well-designed.

Packages

[arrianus]

A package is a file that contains information needed to install and uninstall a program. They are similar to MSI files, but have a number of advantages, mostly stemming from the fact that free software is, well, free, and so you can get it without buying it. Proprietary software comes on CDs, whereas free comes over the Internet. Upgrading free software is very "light weight" whereas upgrading proprietary software is usually very "heavy weight." This gives a different distribution model.

This has several effects. If I distribute a nonfree 10MB program UberTool, that requires the nonfree 20MB MegaLib, I'd better distribute MegaLib with UberTool. If both are free, I can distribute them seperately -- if the user already has MegaLib, he'll just install UberTool.deb. If he doesn't, the package management system will know where to grab MegaLib from, will download MegaLib.deb, and install it.

Furthermore, if I'm going from Office 97 to Office 2000, it's because I bought money on a CD, and I'm running an installer. In the free software world, upgrades are no-brainers, since they cost no money, and most free software programs are a smooth evolution, rather than major versions every several years. As a result, I'll generally be running the latest version of my office suite (as well as every other little utility on my system), and it is convenient to be able to do the upgrades all in one step (apt-get upgrade; apt-get update will grab all packages with newer versions, and install them, cleanly removing the previous ones). Most people never reinstall Debian -- I know installs from '96 that are still running today, at the latest versions, and there are almost certainly ones from before. I don't know of anyone who went from DOS/Windows 3.1 through Windows XP with just upgrades, and without a reinstall.

The next thing is Windows has a problem of bit rot. If you leave a Windows system without reinstalling the whole thing, adding and removing programs, etc. crap builds up. You get all sorts of registry keys you don't need, .dll files you don't need, weird interdependencies, and the system gets slower, more bloated, etc. This doesn't happen on Debian -- I installed my box maybe 3 or 4 years ago, and it's identical in functionality to if I installed it yesterday. Package management, well implemented, buys you that. You never reinstall the overall system, and upgrades are well-managed and don't break things.

The other place package management helps is in centrally-maintained networks. You can install the same package, with the same configuration settings, very easily from a centralized location.

So package management is, in effect, a fancy way to install and uninstall files. However, the fanciness buys you a lot. The new Windows installer is a form of package management, and gives some of the same advantages, although it's not yet as mature as the GNU/Linux ones (.deb has been around since at least '95, and .rpm even longer).

Is this such a good idea?

[Gilesx]

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

Re:Don't leave out Gentoo!

[Al Al Cool J]

once you're old enough to shave and start using real UNIXes you will realize what a waste of time all that compiling and over-optimizing is.

If you just stare at the screen and watch the code compile, then yes, that would be a waste of time. Most Gentoo user though are smart enough to know how to multitask. While program foo is compiling, you do something else, either on the computer, or (and here's the really shocking bit) away from the computer.

So with that in mind, please explain to me how typing

emerge foo

is in any way a waste of my time?

Re:Don't leave out Gentoo!

[V.P.]

I've been doing an emerge -u world for about 2 years now and have never ever had a problem.

Two years huh? How's the good ol' 386SX going?

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.

Gentoo and Portage

[SwansonMarpalum]

As usual I'll come out with my Gentoo Zealotry but I'd like to deflect some of the problems I'm seeing mentioned here.

Gentoo is a Linux distribution largely centric to the Portage package manager (there are other features of Gentoo, but Portage is by far the most conspicuous)

Portage is a package manager loosely inspired by FreeBSD's ports system. Portage maintains a global software configuration file called make.conf. Make.conf holds meta-configuration settings about your system. As Portage builds all programs from source for your machine, make.conf is the place where you describe your machine to Portage. make.conf also holds a collection of use flags. Use flags are global binary switches. They have a default value if they are unspecified, and if you include a Use flag (ie USE="java") then it turns that flag on, and if you include -flag, (ie USE="-java") then it explicitly will not use that feature which is globally recognized by Gentoo.

I see complaints that emerge VI tried to build X and thus portage is "smarter" than you as a sysadmin. This is patently false and ignorant. Portage lets you do your job as a sysadmin once and then never have to worry about doing it again. If you do not want X on a machine then you need merely put "-X" in your use flags.

It puts control in your hands. If you want an application built to support certain things you can have it. If you do not want to support other things explicitly it will do that. It defaults tod doing what's sensible for most people who use Linux casually. If you aren't a casual user, spend a week or so getting familiar with portage and it's configuration. emerge is an incredibly potent tool. All of my systems are patched automatically every day, from source, with the configuration I have specified for that system. My binaries are all built with -march for the CPU, and -Os. And I've never once had any of my systems have a failure caused by misconfigured dependencies. They stay up to date and I don't have to worry about it.

If you want to do all your dependency checking yourself, you're welcome to. However there's a good solution that takes care of all of the issues revolving around this available, freely, to the world. Click here to find out more about it.

Where ports excels..

[Joseph Vigneau]

I was a long time Debian user, and I've "switched" to Gentoo. The primary reason I feel the ports/portage system is better is that I am not forced to install packages that have dependencies on other packages I don't need. For example, take gaim. In Debian, gaim has a dependency on NAS (Network Audio System), so I'm forced to install it. I don't need NAS. I don't want to install NAS. Gentoo has a USE flag that allows me to declare that I don't want anything to use NAS.

Also, it is pretty easy to make a custom "ebuild" file (which is a shell script) in Gentoo, and relatively difficult to create a new .deb. Say a new release of your favorite software comes out, but the package maintainer hasn't gotten around to packaging it. In Gentoo, in most cases, you simply copy the old ebuild file, and possibly tweak the version number. You don't have to download, compile, and package it seperately, as you'd have to do in Debian.

There is also a lot less political activity in Gentoo, and they seem to Get Things Done.

Re:Dependancies

[IamTheRealMike]

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.

Re:Don't leave out Gentoo!

[Tony Hoyle]

Last time I tried that id upgraded glibc, screwed it up and I had to fdisk/reinstall to get the damned system back.

My major gripe with portage is it doesn't record USE flags - eg. if you install links with 'USE=-X' to avoid its dependency on XFree (which moron decided that one???) then then next time *anything* decided to upgrade links it'll rebuild all the X dependencies back in.

That's a real pain when you're talking about things like the java depedency to libdb for example, which doesn't actually work...

Re:Distribute deps

[spitzak]

This is exactly what should be done, but people here are too brainwashed to admit that perhaps some features of Posix should be changed.

It is possible to fake this, we do it with our commercial Linux software, and it is obvious that other commercial software does this:

*All* files for your software are dumped into a single directory, so installation and removal is trivial (this is similar to OS/X App directories). In that directory is a single "wrapper" executable, usually with the name of your program, and only dependent on glibc. The main thing this program does is read /proc/self/exe and use it to setenv LD_LIBRARY_PATH, and locate the actual executable. It then exec's the actual executable. In our case the wrapper also makes sure argv[0] is a clean full path name so the actual executable can use it to locate data files and plugins, you could also put this function in the main program if you wanted.

We then install Gnome and KDE shortcuts on their start menus directly pointing at the full pathname of the executable. Anybody who wants to run it from a shell has to type the full path or symbolically link it themselves into a directory on their path. Deleting our software leaves these start menu items and any symbolic links pointing at nothing, which as far as I can tell is not a real problem.

Intelligent users can easily peek into our directories and see that we ship libtcl and some others in an attempt to hide system differences. They can rename or remove these to better integrate the software into their system. But at least it works, first time, for any users.

I would like to see Linux altered to handle this cleanly, by adding direct support for "app directories". Unlike OS/X, I think they should be named with no extension. The rules are simple: if the user tries to run "foo" and it is a directory, it tries to run "foo/foo" after first adding foo to the LD_LIBRARY_PATH and after fixing up argv[0] to be the full expanded path to foo, and possibly other fixes for stupid Posix rules. This would get rid of 99% of the "install" headaches.