Best way to Manage Packages Compiled from Source

Question

I'm looking into trying to find an easy way to manage packages compiled from source so that when it comes time to upgrade, I'm not in a huge mess trying to uninstall/install the new package.

I found a utility called CheckInstall, but it seems to be quite old, and I was wondering if this a reliable solution before I begin using it? http://www.asic-linux.com.mx/~izto/checkinstall/

Also would simply likely to know any other methods/utilities that you use to handle these installations from source?

Answer 1

Whatever you do, make sure that you eventually go through your distribution's package management system (e.g. rpm for Fedora/Mandriva/RH/SuSE, dpkg for Debian/Ubuntu etc). Otherwise your package manager will not know anything about the packages you installed by hand and you will have unsatisfied dependencies at best, or the mother of all messes at worst.

If you don't have a package manager, then get one and stick with it!

I would suggest that you learn to make your own packages. You can start by having a look at the source packages of your distribution. In fact, if all you want to do is upgrade to version 1.2.3 of MyPackage, your distribution's source package for 1.2.2 can usually be adapted with a simple version change (unless there are patches, but that's another story...).

Unless you want distribution-quality packages (e.g. split library/application/debugging packages, multiple-architecture support etc) it is usually easy to convert your typical configure & make & make install scenario into a proper source package. If you can convince your package to install into a directory rather than /, you are usually done.

As for checkinstall, I have used it in the past, and it worked for a couple of simple packages, but I did not like the fact that it actually let the package install itself onto my system before creating the rpm/deb package. It just tracked which files got installed so that it would package them, which did not protect against unwelcome changes. Oh, and it needed root prilileges to work, which is another main sticking point for me. And lets not go into what happens with statically linked core utilities...

Most tools of the kind seem to work that way, so I simply learnt to build my own packages The Right Way (TM) and let checkinstall and friends mess around elsewhere. If you are still interested, however, there is a list of similar programs here:

http://www.dwheeler.com/essays/automating-destdir.html

PS: BTW checkinstall was updated at the end of 2009, which probably means that it's still adequately current.

EDIT:

In my opinion, the easiest way to perform an upgrade to the latest version of a package if it is not readily available in a repository is to alter the source package of the latest version in your distribution. E.g. for Centos the source packages for the latest version are here:

http://mirror.centos.org/centos/5.5/os/SRPMS/

http://mirror.centos.org/centos/5.5/updates/SRPMS/

...

If you want to upgrade e.g. php, you get the latest SRPM for your distrbution e.g. php-5.1.6-27.el5.src.rpm. Then you do:

rpm -hiv php-5.1.6-27.el5.src.rpm

which installs the source package (just the sources - it does not compile anything). Then you go to the rpm build directory (on my mandriva system its /usr/src/rpm), you copy the latest php source tarball to the SOURCES subdirectory and you make sure it's compressed in the same way as the tarball that just got installed there. Afterwards you edit the php.spec file in the SPECS directory to change the package version and build the binary package with something like:

rpmbuild -ba php.spec

In many cases that's all it will take for a new package. In others things might get a bit more complicated - if there are patches or if there are some major changes in the package you might have to do more.

I suggest you read up on the rpm and rpmbuild commands (their manpages are quite good, in a bit extensive) and check up the documentation on writing spec files. Even if you decide to rely on official backport repositories, it is useful to know how to build your own packages. See also:

http://www.rpm.org/wiki/Docs

EDIT 2:

If you are already installing packages from source, using rpm will actually simplify the building process in the long term, apart from maintaining the integrity of your system. The reason for this is that you won't have to remember the quirks of each package on your own ("oooh, right, now I remember, foo needs me to add -lbar to its CFLAGS"), as the build process will be in the .spec file, which you could imagine as a somewhat structured build script.

As far as upgrading goes, if you already have a .spec file for a previous version of the package, there are two main issues that you may encounter, but both exist whether you use rpm to build your package or not:

• A patch that was applied to the previous version by the distribution does not apply any more. In many cases the patch has already been applied to the upstream package, so you can simply drop it. In others you may have to edit it - or I suppose if you deem it unimportant you can drop it too.

• The package changed in some major way which affected e.g. the layout of the files it installs. You do read the release notes notes for each new version, don't you?

Other than these two issues, upgrading often boils down to just changing a version number in the spec file and running rpmbuild - even easier than installing from a tarball.

I would suggest that you have a look at the tutorials or at the source package for some simple piece of software such as:

http://mirror.centos.org/centos/5.5/os/SRPMS/ipv6calc-0.61-1.src.rpm

http://mirror.centos.org/centos/5.5/os/SRPMS/libevent-1.4.13-1.src.rpm

If you have experience in buildling packages from a tarball, using rpm to build software is not much of a leap really. It will never be as simple as installing a premade binary package, however.

Answer 2

I use checkinstall on Debian. It should not be so different on CentOS. I use it like that:

./configure
make
sudo checkinstall make install # fakeroot in place of sudo works usally for more security
# install the package generated