Skip to content
Apr 15 / markg85

The future about the linux package containers and managers

This is the current way of package management with distributions:
- RPM
- DEB
- ebuild

and then some parts of deb’s or rpm’s are even sub devided in other distributions:
RPM
- PClinuxOS
- Mandriva
- Fedora
- And a ton others

DEB
- Ubuntu
- Sabyaon (Sorry, not a deb using system. Thanx, Patrick)
- Debian
- Again a ton others

This on it’s own isn’t a problem. The problem is that nearly each distribution is so much different that
the same package type (rpm) form fedora won’t work on mandriva or the opposite. And it’s the same case with the deb
based distributions. What you can conclude from that is that there is a huge ammount of people making packages
for distributions but that work das to be done a dozen times to get it working on atleast all the big
distributions (try to install the KDE4 packages from fedora on Ubuntu) which is just so extremely time
consuming and not effectively done at all! So that all has to change and that idea is comming now.

In order to change this all there needs to be one single big package database that works on all the
linux distributions. One compiling cluster and one management system for them. Now imagine that there
would be one place to do all that! that would solve the issue of not having a generic package type.

Now lets dig in this a little deeper. Imagine that you only would have to supply the following information
when submitting a new package for a certain distribution:
- Where files need to be saved
- What patched need to be applied
- Does there need to be an icon anywhere (desktop/menu)
- And some generic package information

Then let the cluster compile it and search for files it provides/requires and which ones need to go in the %files
directive (in rpm atleast) then you don’t have to worry about it anymore and making new packages would go a lot
faster if the compile cluster could determine those things. For that it also needs to be ble to determine the code
it’s written in, what includes are being used and a ton of other things to check but that’s all possible. Extremely
hard but possible to make and would probably require years before it’s complete. Now the best thing would be that
if a package has been added to the database that any other participating distribution in that database can also use
that same package without making any modifications. Oke.. it (should have) the ability to include it’s own patches
or things like that.. Example: If you would make a K3B package for a EU based distribution you can just include the
mp3 support (and some other things) but if you make it for an USA based dist those things will likely need to be
turned off because of possible patent lawsuits. But in general the idea is that you have one place for all of it
and any dist can use it once it has been made once!

Now for this to happen a few other things need to happen first.
- All distribution (that participate) need to agree on the locations where they place files (libraries, images etc.)
- They all need to make deals on the standards they want and don’t want to use
- NO bypasses to fix something that another dist doesn’t have yet.. if it means it could break packages
- And i’m sure there is a LOT more

This will also have a few downsides for dists that participate.. they will all have to make the same changes in order
to stay compatible with each other so that all those packages can still be used on all dists but i’m sure that
it’s something that the dist people can work out. There will also be dists that will likely refuse to join because
they simply disagree with some of the choises or whatever reason.. but i expect that to be just a handfull of
dists (mostly the paid ones i guess).

3 Comments

leave a comment
  1. Robert / Apr 15 2008

    IMHO your idea is broken. There are too much differences between the distributions which cannot be solved by using one single database. Different patches, different base software components such as glibc in use.

  2. Suro / Apr 16 2008

    Hi there!
    The ideas You give are from the family “*nixes of the world UNITE”.
    And of course it has it’s pros and cons.
    Pros:
    It will take less developer time to create packages.
    It will be easier for ISV’s to package their products.
    User experience won’t change while switching from one distro to the other.

    Cons:
    User experience won’t change while switching from one distro to the other.
    It will kill the idea of free software (i.e. no more forks no more differences no more FUN).
    It’s virtually impossible to maintain a cluster with so many users. They eventually will disagree in some simple problem and fork the cluster :D
    It will take less developer time to exploit a vulnerability and the exploit will be compatible with all the distros.

    OK… That are just my thoughts :)

  3. Patrick Ohearn / Apr 16 2008

    All information on the Sabyaon (which you have spelt incorrectly) website, point’s to it using the Gentoo ‘ebuild’ format, not deb.

Leave a Comment