Documentation< Previous | Contents | Next >
8.3.3. Working with Several Distributions
Given that apt is such a marvelous tool, you will likely want to dive in and start experimenting with packages coming from other distributions. For example, after installing a Kali Rolling system, you might want to try out a software package available in Kali Dev, Debian Unstable, or Debian Experimental without diverging too much from the system’s initial state.
Even if you will occasionally encounter problems while mixing packages from different distribu- tions, apt manages such coexistence very well and limits risks very effectively (provided that the package dependencies are accurate). First, list all distributions used in /etc/apt/sources.list and define your reference distribution with the APT::Default-Release parameter (see section 8.2.3, “Upgrading Kali Linux” [page 179]).
Let’s suppose that Kali Rolling is your reference distribution but that Kali Dev and Debian Unsta- ble are also listed in your sources.list file. In this case, you can use apt install package/ unstable to install a package from Debian Unstable. If the installation fails due to some unsat- isfiable dependencies, let it solve those dependencies within Unstable by adding the -t unstable parameter.
In this situation, upgrades (upgrade and full-upgrade) are done within Kali Rolling except for packages already upgraded to another distribution: those will follow updates available in the other distributions. We will explain this behavior with the help of the default priorities set by APT below. Do not hesitate to use apt-cache policy (see sidebar “Using apt-cache policy” [page 199]) to verify the given priorities.
Everything relies on the fact that APT only considers packages of higher or equal version than the installed package (assuming that /etc/apt/preferences has not been used to force priorities higher than 1000 for some packages).
Using apt-cache policy To gain a better understanding of the mechanism of priority, do not hesitate to exe- cute apt-cache policy to display the default priority associated with each package source. You can also use apt-cache policy package to display the priorities of all available versions of a given package.
Using apt-cache policy To gain a better understanding of the mechanism of priority, do not hesitate to exe- cute apt-cache policy to display the default priority associated with each package source. You can also use apt-cache policy package to display the priorities of all available versions of a given package.
Let’s assume that you have installed version 1 of a first package from Kali Rolling and that version 2 and 3 are available respectively in Kali Dev and Debian Unstable. The installed version has a priority of 100 but the version available in Kali Rolling (the very same) has a priority of 990 (because it is part of the target release). Packages in Kali Dev and Debian Unstable have a priority of 500 (the default priority of a non-installed version). The winner is thus version 1 with a priority of 990. The package stays in Kali Rolling.
Let’s take the example of another package whose version 2 has been installed from Kali Dev. Ver- sion 1 is available in Kali Rolling and version 3 in Debian Unstable. Version 1 (of priority 990—thus lower than 1000) is discarded because it is lower than the installed version. This only leaves ver- sion 2 and 3, both of priority 500. Faced with this alternative, APT selects the newest version, the one from Debian Unstable. If you don’t want a package installed from Kali Dev to migrate to Debian Unstable, you have to assign a priority lower than 500 (490 for example) to packages coming from Debian Unstable. You can modify /etc/apt/preferences to this effect:
Package: *
Pin: release a=unstable Pin-Priority: 490
Package: *
Pin: release a=unstable Pin-Priority: 490