1

Suppose I 'apt-get install somepkg', then further install other packages ('abc' and 'def') that depend on 'somepkg'. Later, I might read that there are some desirable updates in the package's latest released source but I can see the pre-built version available through the package manager is stuck on a really old version, so I then get, make, and install from latest released source.

However, I now see that I have 2 different versions/sets of the various built/installed packages. E.g. /bin/somepkg-tool (v 1.0), /usr/bin/sompkg-tool (v1.0), along with the newer, built-from-up-to-date-src /usr/local/bin/somepkg-tool (v4.1), which raises a few questions -

  1. Might there be problems from having multiple sets of the binaries installed from different versions (one from the pre-built package manager and one from locally built latest src)? It feels like a source of potential problems that is best avoided.
  2. If I were to remove the older pre-built managed package with 'sudo apt-get purge somepkg', that now prompts to also remove the dependent packages 'abc' and 'def', which makes me uncomfortable because it's not clear whether that's strictly necessary or whether they can continue to work by finding the newer built binaries on the path. Is removing/purging a previously installed package inevitably going remove subsequent dependent packages? Also, if I accept the removal of the dependent packages, will/can the package manager see that subsequent (re)installing of 'abc' and 'def' no longer require fetching and installing the old 'somepkg', since I have locally built and installed the necessary 'somepkg' binaries from src?
  3. or is there some way of purging the older installed 'somepkg' through the package manager without removing the 2 dependent packages?
  4. Is there a general best way to resolve this kind of situation, or is it usually best handled on a case-by-case basis?

I noticed a similar unanswered question here but, the comments focus on the specific case being rather problematic because it's a fundamental dependency for many things.

Without wanting to distract from the general nature of this question, it may be useful to illustrate a specific case -

  • I 'apt-get install git' (v2.30.2)
  • I later 'apt-get install gitolite3' and '... git-lfs'.
  • Later, I see a number of fixes/updates in release notes and my debian package manager tells me the latest git package is stuck on an older version (apt-get update, apt show git) so I 'wget ...git-2.37.3.tar.gz', make, and install from a newer release source.

Now I see that I have the following binaries (among all the others that come with the git package) -

  • /bin/git (v2.30.2 old)
  • /usr/bin/git (v2.30.2 old)
  • /usr/local/bin/git (v2.37.3 new)

and would like to be sure to avoid problems from the dependenty gitolite repository server and LFS server from inadvertently using the older git binaries. Hence these questions.

Chuffleton
  • 25

2 Answers2

1

  1. If you always know how the PATH is set, you can control this, but yes, this can be a source of problems.

  2. The package manager only knows about packages; it doesn’t know about the binaries you’ve installed manually.

  3. You can use equivs to create a dummy package for the purposes of satisfying dependencies. See How to make apt ignore unfulfilled dependencies of installed package?

  4. See How can I install more recent versions of software than what Debian provides? for a better approach to this, especially for a package like git where newer versions are already packaged — if they aren’t available in backports (2.34.1 currently for Debian 11), you can rebuild an actual package using the newer source packages.

Stephen Kitt
  • 434,908
  • Thanks. Plenty of new stuff for me to digest. Backport examples proceed as if the admin has advanced knowledge of whether to install from the backports packages right from the start. Must we first 'apt remove/purge ...' the installed older package (and dependent pkgs) before explicitly pointing at and installing a newer backports version or will the addition to the sources.list allow upgrading an already installed, older, non-backport package to a newer backports one (i.e. sudo apt-get upgrade git/bullseye-backports) generally without any problems? – Chuffleton Sep 21 '22 at 09:29
  • You can upgrade from backports without installing the previous package with sudo apt install -t bullseye-backports git. – Stephen Kitt Sep 21 '22 at 09:34
  • Just to be clear, since that would seems to be installing a new git package explicitly from backports. My hypothetical scenario is: sudo apt install git ... Oh dear, that's an old version but there's a newer backport version, so will then doing sudo apt install -t bullseye-backports git automatically upgrade the previously installed git? If so, is that going to do anything different from sudo apt upgrade git/bullseye-backports which indicates it recognises and will perform an upgrade to git? – Chuffleton Sep 21 '22 at 10:55
  • There can only ever be one version of a given package installed, so installing git from backports replaces whatever version is currently installed, if any. apt install is used both for installing and upgrading named packages; apt upgrade upgrades everything, it ignores any additional non-option arguments (so apt upgrade git/bullseye-backports won’t actually install git from backports, it will upgrade any upgradable packages). – Stephen Kitt Sep 21 '22 at 11:07
  • Aha. I wasn't aware that 'apt install ...' is really more of a 'install or upgrade'-style process. Thanks for all the help. – Chuffleton Sep 21 '22 at 12:14
  • apt install is intended to be idempotent; if it succeeds, you have the requested packages installed and configured, whatever that entailed (installing from scratch, upgrading, or nothing at all if the packages were already up-to-date). – Stephen Kitt Sep 21 '22 at 12:37
0

With two different installation systems (from the package manager and compiled/installed "manually" by a local admin), it's very easy to end up with:

  1. The main command/daemon is located in two different places. Some users find one place, others find the other, and the difference in versions causes differences in behavior - confusing to all the users. This is particularly the case with a daemon that users may stop and start themselves.
  2. The configuration dirs/files are in two different places, causing complaints when someone updates the config file for the version they aren't using.
  3. With a daemon, the logfiles for the two versions are usually written in two different places, causing confusion and delaying the debugging or troubleshooting efforts of a user or a server admin.

Avoid hand-installing duplicate programs as much as possible. If you must do it, create copious documentation on what programs you have installed this way, and how you compiled/installed them. Adding configuration to the package manager to prevent it from installing the packages you don't want (with verbose comments in those configs) is also an important thing to do. Make it easy on the next system admin who comes after you to maintain and update these programs. (Often that "next" admin will be you, in 9 months when the memory of these details has faded)

Sotto Voce
  • 4,131