0

I'd like to install a software of which there is only a very outdated version in (latest) Debian's repositories (and no other repository to add). To do so I need to compile/install it from source.

Should I uninstall older versions first? It works without doing so but I'm wondering what the recommended procedure is and whether any problems could arise when one doesn't do so (and which).

For instance could there be any problems with dependencies or are the installations somehow properly isolated from another?

2

When you install from source (using sudo make install), you are responsible for choosing the installation location.

Many software packages will by default install under /usr/local if installed from source, but you should check the build instructions of the source package and/or run a dry-run installation (often make -n install, but refer to the build instructions) after building the software but before installing it for real.

When installed under /usr/local, the software usually should not interfere with the packaged version provided by the distribution, and since the PATH environment variable for regular users normally includes /usr/local/bin before /usr/bin and /bin, the locally built version will usually take priority over the packaged version.

So all should be fine immediately after the installation. But it might become a problem later, when the distribution has been upgraded and the locally-built installation is older than the one packaged by the distribution. If you install locally-built software with sudo make install, the source package may or may not include a corresponding sudo make uninstall procedure - and if you have deleted the build directory, the auto-generated Makefile that might have contained the correct uninstall steps might be gone anyway.

So, if you use sudo make install, you should record the output of the installation procedure, or otherwise make sure you'll note which files were added by the installation phase, so that you can manually remove them later. Plan ahead. (If the system in question is a single-purpose server, it might be the only software built from source, and so all the files in the /usr/local/ hierarchy might be produced by that installation - so it might be just a matter of deleting all the files from the directories under /usr/local after a major version upgrade.)

If the source package happens to include the debian/rules file, then the source code already includes the configuration necessary to build an actual Debian package. In that case, you can use dpkg-source -b instead of the generic source building instructions, and the result should be one or more .deb packages you can install using the package manager.

If the packages are named the same as the distribution's corresponding standard versions, but the version of your locally-built packages is higher, your locally-built packages will automatically be used to replace the distribution's version. Just as when installing distribution-provided updates, the package manager will automatically remove the old version of the package and replace it with the new one.

(You might get a warning from the package manager unless you take extra steps to cryptographically sign the packages you built, depending on which package management tool you use, but since you just built the packages yourself, you presumably trust them.)

In this case, once the distribution's package repository has a version of the software that has a higher version number than your locally-built package, the package manager will automatically suggest an upgrade, just like when upgrading the standard packages.

With both the generic source build instructions and the Debian-specific dpkg-source -b, if the software package you're building depends on some libraries, you'll not only need to have the compatible versions of those libraries installed (the build instructions will usually list the required minimum versions of the required libraries) and also the development packages for those libraries, so that the compiler will know how to use the libraries.

The name of the development package is usually the same as the name of the corresponding library package with a -dev suffix added, but sometimes the library package name may include some version numbers that are omitted from the development package name. (In these cases, there may be several versions of the library available for backward compatibility, but the development package either covers both or just the newest version.)

It sounds like you've already compiled the new version successfully, so this is probably not relevant to you... but when building a newer version of software from source, you might find that it needs a newer version of some library or other than is available in the distribution... and a newer version of that library needs a newer version of some other library to compile... and so on. While it's possible to traverse the chain of dependencies and build local versions of the required libraries if there are not too many of them, it is important to not go too far. Providing new versions of one or two special-purpose libraries is probably fine, but if you start building upgraded versions of libraries that are used by several system components, you probably should consider switching to a newer distribution instead. Compiling a new version of glibc locally and installing it for system-wide use is right out.

1

The TL;DR answer is it depends, 'never touch a running system' if everything works as expected, unless you know what you're doing or feeling adventurous :) But using apt remove <software> (or similar) is relatively safe, and version conflicts or broken dependencies through this route are rare (for software you also installed through apt).

Manually, as a first step, you can check dependencies of your software by using

ldd --verbose <program>

but that can get complicated quite fast - my advise would be, never just blindly remove a library just because your old software installed it. It may also be used by other programs.

Different versions of libraries are normally well 'isolated' through proper naming conventions. Unfortunately, you can always introduce problems by installing a broken shared library. In that case you have to reinstall that library or depending software entirely. You can mitigate follow-up problems by thinking carefully which software you install in the first place (maybe set up a virtual system that mirrors yours and test it there).

Of course, the above is just true for shared files. Files and directories the installation put into your /home/ can be removed with relative confidence. Exceptions may be Gems, Shards or python packages etc, but those can be reinstalled relatively easy. Also, if you generated access-keys or unlock codes, first backup before you remove.

Of course, answers on that topic can range from "Just do it" to "Never touch it", and there sure exist many opinions surrounding that topic.

Hope that helps a bit.

0

A standard practice in Linux is to install new software from sources into /usr/local or /opt which means there's no need to uninstall already installed software.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.