Packaging LSB packages – a first glimpse

packageIn my opinion the current software-packaging/software-install system for Linux systems is a crappy thing:
Every distribution packages the most interesting and important packages for itself: KDE stuff, GNOME, compiler, apache, and add on packages like firefox. Therefore, each work is repeated not only twice but dozens of times. For Suse, for Fedora Core, for Ark Linux, for Debian, for Ubuntu, and so on. And the packages are usually not compatible between the different distributions.
This is dumb – I must know it because I’m part of the game (I package ktorrent and rsibreak for Fedora Core).

The reasons behind this is well known: there was no standard at the beginning, and therefore everyone did it his/her own way. These ways were different sometimes, depending on the roots of the packager. The result is as already mentioned: duplicate work (ha, if only, multiplicate work is closer to the truth), incompatibility – and the worst result is that software for Linux is usually released as the source code only, without any chance for an average computer user to install it.

Of course there are different attempts around to solve this problem: klik, zero-install, autopackage, etc. They all are honest attempts, all with very interesting advantages, but also with shortcomings. In any way, they are all more or less uninteresting because none of them really spread wide enough to really solve the problem.

But there is one attempt which spread at least wide enough to be interesting and which could solve this problem: I mean the LSB and the FHS standards of the Free Standards Group. Both are made to create a reliable platform on which everyone can install software cross all (LSB compliant) Linux installations.
While the FHS defines where files should be installed (and other things), the LSB defines how a binary package should be created a build, how it should look like, and so on. Also, it says what you can expect on such a system.

Sounds perfect, doesn’t it? It is even easier for me because the basics use an already existing format, the rpm package, which is used by Fedora Core also.

However, I now had the first glance at that book which describes all these things. But it was disappointing in some ways:
First of all this book seems to be outdated because some examples refer to the LSB v. 2.0 instead of 3.1 and the quality of the important graphics in the book is horrible.. Second, some rules are a bit strange: for example, you are supposed to install binary applications to /opt/, and the binaries have to be at /opt/application/bin. Well, so far so good. But you are not allowed to create links of the binary and the libraries to standard, path directories (see section 4). So as far as I see it this must be done by the system administrator himself – without this the application can only be launched with a direct link to the /opt/application-name/bin directory. Something I do not like at all…

On the other hand it is said that applications which are provided as source-rpm or tar packet should be installed to /usr/local/ – the question for me is now if this means all packages generated from Open Source code, or just packages build by the admin of the system himself.

Also, at least at this first glimpse I did not get the idea how this could help with a problem of installing applications twice: for example, ktorrent is definitely not part of the main Fedora system – it is a nice add on, that’s all. But it is installed to /usr/ – what happens now if someone starts to produce a LSB compliant package for ktorrent and this is installed in /opt. Than it would be on the system two times. How can we avoid that?
Also the LSB references seem to be flexible about the installation directory, if you install your package to /opt/application-name or to /opt/company-name/application-name. That again would mean that there could be installed two versions on one system. Ok, if two people try to build LSB compatible packages, seems to be unlikely…

However, the first glimpse was in a way disappointing, especially the thing with the admin-created links. All other stuff is unusual for me, but could be realised, I hope. I would like to create LSB packages for some applications, and if I would get used to it, I would try to create even more and more. But, well, first let’s start with one single package. I guess I should join some e-mail-list to realize that…

6 thoughts on “Packaging LSB packages – a first glimpse”

  1. Don’t forget the GoboLinux approach to this problem which seems to offer a quite unique approach (Well maybe it is just an application folder dressed up). I got in to an argument about this at the first LugRadio and the only remotely interesting argument against was “do you think that the unix guys didn’t know what they were doing” but things have changed since then and so what the Unix guys thought isn’t as relevant as it was then (referring to the change of the entire file system and not package management (File system and Package management are very much related especially in Gobo’s case)) and my only prob with Gobo (apart from polish) is such a change would find way too much resistance even in the tech crowd who I thought would embrace trying out new ways of doing things (and the effort that comes along with that)

    I really should learn to use better sentence structure than adding bits in with brackets🙂

  2. Sure, there are much more approaches: besides GoboLinux with its unique path structure there is rpath with a different kind of packaging systems. Also approaches to copy the BSD system where you have a clear border between system components and additional components are interesting and probably worth mentioning.

    But I already mentioned them – with the “etc.”. The thing is: none of these efforts, no matter how honest, cool, shiny, new or intelligent they are, was good enough to spread its wings enough.

    And about the crowd and embracing new ways: sure, the crows is always willing to embrace – that’s the reason why there are enough people to fire up a new Linux distribution every day. But as with every new approach to common problems: when the solution is good enough, then it is accepted or at least tested. Gentoo spread wide enough with its new idea, everyone accepted almost immediately NetworkManager, Ubuntu is going to try a complete new replacement for init.d, the XML package metadata format is accpeted by more and more distributions, X.Org replaced XFree86 over night, and so on.
    But when the solutions are not mature enough, or introduce new problems, than they are not included at all – there are enough solutions which never made it to the critical mass: Elektra, the already mentioned autopackage, and so on.
    And at least at the moment, GoboLinux haven’t reached this critical mass, because they weren’t able to communicate there solution good enough: The replacing of the whole init.d system (which is typical Unix) is a probably even more revolutionary attempt. And it is now introduced into one of the most spread distributions around.

    So, as a summarize: the approach of GoboLinux is not too revolutionary – it is just not communicated well enough. Revolutions can happen. Convince enough people that it is necessary and that your solution is the best to the problem.

  3. I guess there is no silver bullet yet, just a number of solutions that are better than what we have (most things are better than disarray between vendors). I can’t seem to find any real info on rpath just a few flash clips on their website that convey little detail but I assume it is equivelent to producing multiple binary debs and keep everything you need in one file (or even worse duplicate libraries for every app you install which is bad for system wide upgrades and wasting disk/memory space).

  4. Just to add another attempt to solve the problem: at the akademy BoF sessions there is this talk dealing with the same subject. I really hope I will get some information about that sometime soon.

  5. I have emailed Maichael’s Leibowitz’s intel address to see where I can get more info as I think getting this problem corrected is essential for linux as a whole and I should learn as many approaches to this problem if I’m ever going to contribute to a working solution.

  6. As you can imagine I am very interested in every response! Especially in his talk because I hope that there are some more information about what is possible. Keep me up2date, at the moment I just update the akademy bof page in the hope that there will be a link somewhen…

Comments are closed.