Kali Linux Revealed

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
8.3.4. Tracking Automatically Installed Packages
One of the essential functionalities of
apt
is the tracking of packages installed only through de-
pendencies. These packages are called automatic and often include libraries.
With this information, when packages are removed, the package managers can compute a list of
automatic packages that are no longer needed (because there are no manually installed packages
depending on them). The command
apt autoremove
will get rid of those packages. Aptitude does
not have this command because it removes them automatically as soon as they are identified. In
all cases, the tools display a clear message listing the affected packages.
It is a good habit to mark as automatic any package that you don’t need directly so that they
are automatically removed when they aren’t necessary anymore. You can use
apt-mark auto
package
to mark the given package as automatic, whereas
apt-mark manual package
does the
opposite.
aptitude markauto
and
aptitude unmarkauto
work in the same way, although they
offer more features for marking many packages at once (see section 
8.2.7.1
, “
Aptitude
” [page 196]).
The console-based interactive interface of
aptitude
also makes it easy to review the automatic
flag on many packages.
You might want to know why an automatically installed package is present on the system. To get
this information from the command line, you can use
aptitude why package
(
apt
and
apt-get
have no similar feature):
$ aptitude why python-debian
i
aptitude
Recommends apt-xapian-index
i A apt-xapian-index Depends
python-debian (>= 0.1.15)
205
Chapter 8 — Debian Package Management

8.3.5. Leveraging Multi-Arch Support
All Debian packages have an Architecture field in their control information. This field can contain
either “all” (for packages that are architecture-independent) or the name of the architecture that
it targets (like amd64, or armhf). In the latter case, by default,
dpkg
will only install the package
if its architecture matches the host’s architecture as returned by
dpkg --print-architecture
.
This restriction ensures that you do not end up with binaries compiled for an incorrect architec-
ture. Everything would be perfect except that (some) computers can run binaries for multiple
architectures, either natively (an amd64 system can run i386 binaries) or through emulators.
Enabling Multi-Arch
Multi-arch support for
dpkg
allows users to define foreign architectures that can be installed on
the current system. This is easily done with
dpkg --add-architecture
, as in the example below
where the i386 architecture needs to be added to the amd64 system in order to run Microsoft Win-
dows applications using
Wine
5
. There is a corresponding
dpkg --remove-architecture
to drop
support of a foreign architecture, but it can only be used when no packages of this architecture
remain installed.
# dpkg --print-architecture
amd64
# wine
it looks like wine32 is missing, you should install it.
multiarch needs to be enabled first.
as root, please
execute ”dpkg --add-architecture i386 & apt-get update &
apt-get install wine32”
Usage: wine PROGRAM [ARGUMENTS...]
Run the specified program
wine --help
Display this help and exit
wine --version
Output version information and exit
# dpkg --add-architecture i386
# dpkg --print-foreign-architectures
i386
# apt update
[...]
# apt install wine32
[...]
Setting up libwine:i386 (1.8.6-5) ...
Setting up vdpau-driver-all:i386 (1.1.1-6) ...
Setting up wine32:i386 (1.8.6-5) ...
5
https://www.winehq.org/
206
Kali Linux Revealed

Setting up libasound2-plugins:i386 (1.1.1-1) ...
Processing triggers for libc-bin (2.24-9)
# wine
Usage: wine PROGRAM [ARGUMENTS...]
Run the specified program
wine --help
Display this help and exit
wine --version
Output version information and exit
# dpkg --remove-architecture i386
dpkg: error: cannot remove architecture ’i386’ currently in use by the database
# dpkg --print-foreign-architectures
i386
APT will automatically detect when dpkg has been configured to support foreign architectures
and will start downloading the corresponding
Packages
files during its update process.
Foreign packages can then be installed with
apt install package:architecture
.

Download 11,68 Mb.