How to Upgrade a Package in Linux That Was Built from Source

How to upgrade a package in linux that was built from source?

if you are building from source, then there is no concept of "upgrading" as there is no database where the version of the software is being registered (one of the features of a package manager). just build the new code exactly as you did the previous code.

How to update programs built from source

That depends. If it simply minor update, just go for recompilation and make install.

If any changes in supplied libs and/or header files were done (e.g. they were renamed), you better uninstall software first to get rid of unneeded files on your filesystem.

Best way to Manage Packages Compiled from Source

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.

How do I update a Python package?

You might want to look into a Python package manager like pip. If you don't want to use a Python package manager, you should be able to download M2Crypto and build/compile/install over the old installation.

Upgrading a package whose newest version is not still in the distribution repository

I have not found out how to upgrade and replace a package whose newer version is not still in the distribution repository. But I have realized that if some library X relies on a given version of other library Y, there is no way to change the version of that dependence unless you make some change onto the source code of X, that is it, the library X is recompiled to point to the desired version (usually with the help of some configuration tag). Even though some trick could be done as by modifying the symlink of the library Y to point to the newer version. Then, the compiler will complain and ask for the old version.

Maybe this looks obvious now. But if the software that has to be recompiled requires many hours, has unresolved dependences or gives built errors you will try to avoid the compilation no matter if you are violating thermodynamics laws.

So in my case I had to recompile Qt and by using the -system-libpng configuration tag Qt understood it had to use system libpng libraries, not in-built ones. And after 8 hours of compiling I got a successfully built which solved this libpng problem.

Thanks everyone for the comments and suggests.

How to build all my installed package from sources?

Is is possible to build Ubuntu from source to get the same kind of benefit?

I am not sure about the benefits if you have fairly new hardware components but for the "Ubuntu from source" part of the question the answer is YES, you can build not only your favorite applications from source, but the entire operating system.

Here is how:

You need to install apt-build. Its a comandline tool like apt-get, but instead of downloading and installing the binary package, apt-build downloads the source code of the package, compiles it and then installs it to your system.

After you install it with

sudo apt-get install apt-build

you will be asked for an optimization level (medium is ok), whether you want to create an apt-build repo for APT (Yes) and a question about processor architecture (my intel i7 is considered core2 ). Of course all options can be reconfigured in this way:

dpkg-reconfigure apt-build

The above command offers two additional options for the gcc compiler and make builder. Their descriptions can be found in system manuals: man gcc and man make.

For a manual and available command options check

man apt-build

But the most useful are:

• apt-build update — updates repo list, (like apt-get update)
• apt-build upgrade — updates operating system, (like apt-get upgrade)
• apt-build install program — installs an application,(like apt-get install)
• apt-build world — something for hard-core users, it recompiles whole system!

For example:

Lets say you want to compile/install Gedit. Instead of apt-get install you just do

sudo apt-build install gedit

Apt-build makes use of deb-src entries contained in the /etc/apt/sources.list file so the compilation and installation processes are fully automatic (similar to emerge found in Gentoo). Apt-build downloads sources of the main application and its dependencies, compiles them, creates a deb package, and finally installs the package.

Some notes about apt-build world.

In my opinion don't attempt it, unless you have 24 or more hours available !

If so first thing you should, remove/disable/uninstall any third party applications (it better to do in a fresh install of Ubuntu) and then do :

sudo su
dpkg --get-selections | awk '{if ($2 == "install") print $1}'> /etc/apt/apt-build.list
exit

The above command will copy your full list of system packages to apt-build.list so that they can be compiled from source.
Open that file

sudo gedit /etc/apt/apt-build.list

and remove any GCC/G++ entry

Then you can do :

sudo apt-build world

I suggest to add two options — --yes and --force-yes — to make the rebuilding process fully automatic.

Install software from source

If you hold the version of postgresql, your package management should know that it needs certain versions of the dependencies. It may update the dependencies as long as the version requirements are met. It will report problems if it would need to update some dependencies which are locked to older versions by the postgresql package.

If you build and install postgresql-10 from source, your apt will of course not update this local installation.

To build it you will probably need some development libraries which refer to the corresponding system libraries. Probably it will be built with dynamically linked libraries, so apt may later update the dependencies (i.e. the libraries needed by postgresql and corresponding development libraries).

This can be even more problematic because your apt does not know that you locally installed a version of postgresql that may depend on specific versions of the dependencies.

The only way to prevent apt from updating anything related to postgresql would be if its build procedure allows to link all libraries statically.

---

Related Topics