Ubuntu/Debian package management is based on the concept of package sources or repositories. A
/etc/apt/sources.list (or separate files in the directory
/etc/apt/sources.list.d) specifies the location of package sources.
When a package is to be installed, all package source locations are checked whether they contain the desired package. If the desired package is found in only one package repository that one is taken, if it is found in more than one, then the package with the newest version is installed.
Package sources are usually specified in
/etc/apt/sources.list and can be of many different
types, like http, ftp, file, cdrom, … (see
man sources.list). In a default Qlustar
installation this file is empty, since all the Qlustar package sources are defined in the file
/etc/apt/sources.list.d/qlustar.list. If your system has access to the Internet either
directly or through a http proxy the file will look like this:
deb http://repo.qlustar.com/repo/ubuntu 11.0-bionic main universe non-free deb http://repo.qlustar.com/repo/ubuntu 11.0-bionic-proposed-updates main universe non-free
This enables access to the Qlustar 11.0 software repository.
man dpkg) is the basic package management tool for Ubuntu/Debian, comparable to
rpm (Red Hat Package Manager). It is not capable of automatically resolving package
apt is the high-level package management tool for Ubuntu/Debian.
man apt) with its
sub-commands provides all the functionality needed to maintain an Ubuntu/Debian system. A
seem-less and fast upgrade of an Ubuntu/Debian system is typically performed running the two
0 root@cl-head ~ # apt update 0 root@cl-head ~ # apt dist-upgrade.
Detailed upgrade instructions for a Qlustar system can be found in the Qlustar Update Section.
New packages can be installed by running
apt install <package name>. If <package name>
depends on, or conflicts with other packages those will be automatically installed or removed
The possibility to concurrently run different versions of the same application on a single cluster is often crucial. In principle, this is achievable in a couple of ways, each one requiring more or less handwork depending on the type of application in question. Fortunately, Ubuntu/Debian provides the built-in alternatives mechanism to manage software versions in automated form. It has the additional advantage that it works appropriately for any kind of application.
Let us consider the case of the GNU C compiler
gcc as an example of the situation described
above. Simply installing the gcc package via
apt is all you need to do in this case. The
alternatives are automatically configured for you.
0 root@cl-head ~ # cc --version cc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
This tells us that currently we are running the version 5.4.0 of the GNU C compiler. Let us inspect the cc binary.
0 root@cl-head ~ # type cc cc is hashed (/usr/bin/cc) 0 root@cl-head ~ # ls -l /usr/bin/cc lrwxrwxrwx ... /usr/bin/cc -> /etc/alternatives/cc
As we tried to locate the
cc command, we found that it was being executed from the
path. However we also discovered, that it’s a symbolic link pointing to
/etc/alternatives/cc. The directory
/etc/alternatives is the place, where all the software
alternatives are configured in Ubuntu/Debian. Let us inspect a little further.
0 root@cl-head ~ # ls -l /etc/alternatives/cc lrwxrwxrwx ... /etc/alternatives/cc -> /usr/bin/gcc
We have another symbolic link, this time referring to
/usr/bin/gcc and a little digging
afterward reveals that this is a link to the real
gcc executable. If alternative versions for
a program are available, the alternatives system will create a link with the name of the
program in the default path pointing to the appropriate file in
/etc/alternatives. This will
finally link to the executable, we actually want to use. Instead of manually manipulating these
links, choosing a different default version for a program should be done using the command
update-alternatives we can quickly figure out which alternatives are currently
configured for a certain executable. Let us look at the current setup of cc.
0 root@cl-head ~ # update-alternatives --display gcc cc - auto mode link best version is /usr/bin/gcc link currently points to /usr/bin/gcc link cc is /usr/bin/cc slave cc.1.gz is /usr/share/man/man1/cc.1.gz /usr/bin/gcc - priority 20 slave cc.1.gz: /usr/share/man/man1/gcc.1.gz
As you can see the current link points to
/usr/bin/gcc as we already discovered. There might
be another alternative, with a different priority. The line
'gcc - auto mode’ means that the
alternatives system will look for the package with the highest priority in order to use that
The last line in the above output says that the current best priority link is
/usr/bin/gcc. If we had installed an alternative for cc and would want to want to use it
instead, we could tell
update-alternatives to use this variant as follows:
0 root@cl-head ~ # update-alternatives --config cc
A further useful feature of
update-alternatives is the possibility of creating groups of
files having a relation with each other. These so called slaves will not only allow you to
update the link to the desired executable, but also any other information related to it like
man pages, documentation, etc. as shown for the cc example above. Please consult
update-alternatives for more information on the capabilities of this powerful software