Slashdot Mirror
How to Make Easy-to-Package Linux Software
jmmv writes "The packages in any Linux distribution (or other operating systems) are a master piece to let the user install any program he wishes as painlessly as possible. However, the creation of these packages is not always free of problems. Usually, the packager finds that the program he wants to package suffers from a series of pitfalls - either conceptual or related to portability - that make the packaging task harder than usual. This is why I decided to write an article (published at ONLamp.com) summarizing these problems and proposing several solutions to each of them, aiming to make the life of the packager simpler. I hope it to be of interest to free software developers and also hope that they understand some of the issues and try to fix them in their creations."
"Avoid modifying published distfiles."
Oh heck yes. The number of times I've been bitten by a few projects (yes mplayer guys, I mean you) doing this and breaking Gentoo's digest system...
http://www.autopackage.org
"A truly wise man realizes he knows nothing."
What the hell else can I say?
There should be a self-installing binary.
Wow, it's so simple and so obvious.
The article is missing a third solution to the Automatic Decisions solutions: gracefully handle at runtime the absence of a (soft) dependancy.
What I mean is automatically enable all options which are available at build time, but don't hard link to them (use dlopen(3) or somesuch instead), so the same binary package would work in the presence or absence of such dependancies.
Of course, without the runtime dependancies, some options won't be available, but it's better to do it that way than to force everybody to download libfoo and libbar to satisfy an optional dependancy, or to arbitrarily disable some options (which will only be available to people building from source, not those using a package. You want your software to be useful, right?).
Depends what you mean by "you". It may not bother the end user, but it will bother everyone else who needs to do other things than just run your install script.
Next, there's distro-based package systems like apt and portage. These work very well, as dependency control is automatic, and it is made to work with your distro specifically.
The third option, which is used by (I think, but am not sure) Loki Installer, and such programs, is to install the binaries, but leave you on your own to deal with dependencies. As long as you make sure the dependencies are easy to obtain, this is one of the best options for those without apt or a similar system. You could even, with GPL software, create your own installer for any dependancies, should you choose.
Why not Autopackage? Because it seems like a format that is, at best, a poor substitute for a package system like apt. The simplest solution, considering how much disk space is available on modern machines, is the folder concept like OS X. Very simple, and incredibly easy to remove programs.
Take a look around. You either get a good method for a few outdated packages, or you get a great system that takes forever to compile packages. Obviously, I haven't dealt much with debian based distros and their magical apt-get, but the major distros like Suse, mandrake, and fedora are still RPM based. I think RPMs have really slowed down linux adoption due to dependency hell. I hope systems like autopackage can help things out.
The amount of times (on Ubuntu) that apt/dpkg have screwed up the config files by replacing packages names with rubbish is thoroughly frustrating. It then outright dies and can't even see where it's made a mistake, here's a clue, % is not allowed to be a package name, how about you go replace it with the character that was there BEFORE you screwed up.
It means I have to go into the extremely long, and messy, database files and fix up the package name myself. I'm not joking when I say it's happened on about 8 installs of Ubuntu (warty). Yet, never on another distro.
Is this a common problem on Debian systems, or just Ubuntu?
Anyway, it's heart wrenching, because usually once it's happened once it happens more and more often with worse effects everytime, until eventually the package manager is hosed and only a reinstall will save it.
doesn't get any easier than that.
Agreed. Red Hat made me want to dive into a river to rid myself of all of these dependency issues, and I was aged by the time X,KDE,Gnome,Firefox,Thunderbird, et al finished compiling on Gentoo. I've got high hopes for autopackage, but haven't used it yet. I think that it is obvious that the thing that is keeping linux off the desktop is the difficulty in installing software. RedHat (and other RPM distros) - if you want to have a completely nontechnical-user environment, you can't expect them to touch a shell at all, and when the fancy RPM GUI crashes and burns, or 9000 unresolved dependency require the user installing to do a little forcing and shodding, it comes to a shell. I hope AutoPackage is *it*. The choice of multiple install options is irreplacable and not something I want to, nor am about to give up, but simplicity is paramount in end-user environments, and most distros lack this when it comes to installs.
sigSEGV - doy!
Mandrake's urpmi does pretty much the same thing, and most people who have installed non-trivial third-party RPMs on Mandrake have encountered dependency unpleasantness. There's also apt-rpm, yum, etc... and they not magic bullets either.
The reason Debian apt works so well is its well-maintained package archive. The archive is huge: the unstable distribution contains over 18000 packages. Apt is at least as good as the other package tools at resolving dependencies, but can only work with the packages that are available to it.
Installing a third party package is usually easy because there's a really good chance any dependency it asks for is in the archive. I thought apt was magic too, when I switched to Debian, but urpmi or yum could do the same thing given an archive as good as Debian's.
So where are your suggestions to improve it?
... <-- the stagnation on Linux user-friendliness: disagreements between developers
You either get a good method for a few outdated packages, or you get a great system that takes forever to compile packages.
Compiling? Who's talking about compiling?
Oh... it's Linux. You HAVE to compile. -.-
I frequently need to package software up for distribution, and have seem bith increadibly easy and next to impossable.
Please please please do NOT make the build system more complex than the app being installed! Inside every 200 line monument to bogosity is a 10 line makefile trying to get out. I'm not kidding. I realise there are a few cases where it's justifiable, but those are a lot less common than people seem to think. When it's easier for a package maintainer to throw the makefiles away and copy in a new one, the line has been crossed.
Seperate the prefix for buinding and the one for installing. Most package systems want to build using the normal system prefix (so any compiled in defined paths will work), but need make install to actually put the packages in a different tree to be packaged up rather than in the system. That is, /usr/bin/app goes into /var/tmp/app/usr/bin/app.
The easiest way is for the makefile to allow for 'make install_prefix=/var/tmp/app install' or even 'make prefix=/var/tmp/app/usr install'. Makefiles that do some final fixup based on the prefix are totally fubar for this case.
Related pet peeves include a 'stable' package that has dependancies on the CVS version of some library. If your depoendancies aren't stable, neither are you! Similarly, the more dependancies you have, the more important it is to not require the latest sub-sub-sub minor version of those dependancies. I needed to install subversion on a year old system, and it was actually easier to wipe and re-install the whole system than to update the dependancies (and their dependancies).
In turn, if you export an API, and it changes enough that a dependant program must be coded for either this version or the last (not both), that calls for a major version number bump. Keep in mind that not every maintainer is holding their breath waiting to do a major re-write for your new API, so it will be best if both major versions may be installed concurrently for a while.
Just to be fair all around, packagers that just have to check the latest version out of CVS implicitly agree that all of the above bets are off. There's a reason it's not yet available as a stable versioned tarball.
</soapbox> There, I feel better now :-)