The future of packaging software in Linux

The polishlinux.org site has an interesting post regarding the future of packaging in Linux.

I have thought on this for quite some time and I think there’s a lot of things to do. I’ll try to explain why I think so. I might make mistakes, specially with debian packaging system as I’ve barely used it; if I do please ping me back.

Today the mainstream packaging systems are built on top of legacy ones (RPM, deb), and lack very basic features. One example is rollback. Let’s say I add a custom repo that replaces some of my packages with development versions, I don’t like it, so I just want to go back to the previous state. One might think such a very basic operation should be easy in this fantastic world of Linux, and one would have thought wrongly. Nor RPM nor deb allow that kind of thing.

All right then! Let’s try to list all the packages that came from that repo. Hmm, again, you are out of luck, nor RPM nor deb(?) have a concept of such a new thing as package repositories.

Of course there are workarounds, but if very basic information as where the package came from is not available what can you expect from your package manager?

  • Can I find the packages I installed, those that came from upgrades, or the ones that came pre-installed? No. Well, perhaps if you write them down.
  • Can I find the unused packages? Of course! you just need to write an application that does that.
  • Can I store my system for later restore? It might be a little hard, but you can write an application.

Well, this is Open Source, someone must be working on adding those features right? Wrong. These are not priorities [1], basically if you want that you shouldn’t use RPM/deb.

So IMHO the future package manager should provide the following:

  • Repository support integrated
  • Rollback support
  • Existence information: added by X (pre-installed,root,john), from Y (repo/url/file), because X (upgrade/dependency)
  • Log history

Imagine the following use case: You have the feeling that there are a lot of packages that you are not really using, instead of going manually through all of them you just want to see the ones you installed and their files haven’t been accessed in a while. Once you have that you want to remove the package and all it’s dependencies, this is tricky, so perhaps a GUI with a three of these packages would help.

The future packaging system

In summary, it’s a bad idea. There’s no way a new packaging system will succeed right now. You need a successful distribution to go with that, otherwise not many people are going to use it.

Can you use Ubuntu without debs? Fedora without RPMs? Gentoo without portage? (perhaps yes, but it would be like Linux From Scratch)

Personally I hate these wars. Fedora/Redhat has its own system configuration applications, it’s custom theme, configuration, etc. The same goes for Ubuntu, SUSE. Every distribution is doing the same thing over and over, and they don’t like to share things, or, at least they don’t make it particularly easy to port their stuff.

If it’s all about freedom then why I can’t I use Ubuntu without debs? There’s nothing that prevents RPMs to do exactly the same job. Packages are tarballs with extra information that allows certain operations. You can use alien for example, to convert one to another.

In fact you can install the debian packaging system in Fedora, or even Gentoo. The same goes for RPM inside Ubuntu. Of course, both expect you to have the whole system managed by them, otherwise you’ll have issues, and don’t even think about interoperability.

It’s software, yet it looks like we are talking about Capitalism vs Socialism or some issue of that sort; you must pick one side and never look back.

There are distribution agnostic alternatives as Autopackage, Zero Install, klik and OpenPKG, GNUpdate but they don’t seem to be quite mainstream yet, even dying perhaps?

Liberation: Step 1

The problem is that we are lazy. Are you familiar with this?

./configure --prefix=/usr

Most of the software assumes it’s going to be installed in /usr or /usr/local. That’s a valid assumption, since most distributions do exactly that.

But what if I don’t have permissions? What if I don’t want to mess with my system?

Most of the time you can install things anywhere you want, you just need to know a couple of tricks. But sometimes it’s very difficult.

In order to avoid this problem there are several tools: stow, graft, depot, ENCAP.

Problems arise when you deal with system software, basically when you are doing your own distribution [2].

There are ways to for example install Apache, PHP, and MySQL under /opt/net, and when you don’t want that just remove it. Or you can have /opt/python-2.5 and /opt/python-2.4 and choose the one you want to use when you start certain Python application that requires one or the other. This of course is not that smooth.

What about /opt/gnome-2.20 and /opt/gnome-2.18? You could easily switch from one another.

Since it’s not that easy you’ll need tools to do the switching.

Liberation: Step 2

Another problem are the build systems.

Let’s compare the guts of the glibc package in the different packaging systems:

  • RPM (Fedora 7): [3]
    Note the ugly hacks, and the usual hugeeeeee ChangeLog
  • deb (Ubuntu Feisty): [4] [5] [6] [7] [8]
    Note that you need several files, and a huge file lists for each sub-package (libc6-doc). At least Fedora’s mess was in one single file.
  • Portage (Gentoo): [9]
    It looks better, but still it’s too simple

This is how LFS recommends to install libc [10] (Much simpler).

Bad build systems lead to complicated package specs. Now archlinux provides the only nice example: [11]

A good package build system would make things easier for adopters, and perhaps if it’s independent of the package management system will make things smoother. I am kind of working on an object oriented approach, but nothing real yet [12]

Liberation: Step 3

So this is what I would like: A package management framework. Each part of it modular, so I can use the same UI for different backends. Perhaps different storage methods, and file formats. After all on doesn’t need to depend on the other.

Kind of like this:

Dream Package Management Framework

About these ads

8 thoughts on “The future of packaging software in Linux

  1. “All right then! Let’s try to list all the packages that came from that repo. Hmm, again, you are out of luck, nor RPM nor deb(?) have a concept of such a new thing as package repositories.”

    Synaptic does it. Its in the main window, through the option to sort packages by origin…

    I can rollback easily from my default ubuntu desktop. In fact, I can do it in a package by package basis, from the GUI.

    Regards.

  2. klik is not dying. Quite in contrast, we are working to make it a system for “application virtualization”, where each software package will essentially run inside its own “jail”, so that it will never interfere with the base system. Want to join development?

    Fore more information, please see the official klik presentation at http://klik.atekon.de/presentation/

  3. Rollback? Easy with klik: Put application.cmg into the trash, done. Application is removed. (Yes, that’s the “One app = one file” philosophy.)

  4. Flavio: I can’t find that “origin” option in my Ubuntu Dapper. Probably because it’s too old? Anyway my best guess is that the “origin” field is not part of the deb database but more an apt thing. I might be wrong, maybe deb can store any kind of information.

    Flavio: I don’t mean rollback as removing a package, I meant undoing an operation.

    If I install a package that has lots of dependencies then rollback means also removing the dependencies. If I install a development repo and I issue an update rollback means going back to the old versions, remove the dependencies of the new packages, and adding the dependencies of the new ones.

    probono: I’m sorry, I didn’t mean to imply that all of the projects where dying: perhaps some. My choice of wording is not usually the best.

    I have seen that presentation and I agree with most of it, you explain some of the key issues IMO—you might want to update the presentation (Gaim – 1.5.0?)— However I’m not sure having each application and all it’s dependencies on the same file is the best solution. I think the best would be to share the dependencies even if they are installed somewhere like $HOME/test/packages/python-3000 or whatever. Some tricks as LD_LIBRARY_PATH/PYTHONHOME can be used.

  5. Some of your goals can be archiwed with gentoo’s portage ;) ( note: I didn’t read your post very carefully, so I might miss something )

  6. jinzo: maybe, I haven’t tried portage that much ;)

    But the key thing here is that I don’t want to compile stuff. I’ve heard that Gentoo can handle binary packages, but I haven’t really seen any of those for Gentoo.

    The key thing here is that I would like the package management system to be independent of the distribution.

  7. Fortunately now there’s Package Kit, so the UI part is done! :D

    Package Kit can be used for rpms, dpkg, or any package management system.

    The next step is to split the build instructions.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s