Over the last several months, there has been an uproar about package formats for Linux (see the "Existing Container Package Formats" box). Canonical garnered attention by announcing with great fanfare its new cross-distribution development [1] and its Snap format [2] (see the "Snap vs. Flatpak" box). The subsequent press coverage seemed oblivious to the fact that Canonical needs to maneuver over some thin ice with these innovations. Everything has a proprietary license and is currently only on Ubuntu with no support from Ubuntu derivatives. These shortcomings escaped the attention of the press but came to light with more attentive testers [3].

Click packages [4] also received similar press coverage, perhaps as a filler for lack of news during the summer months. Looking back, this was a predecessor for Snap. Click continues to have limited meaning for Linux systems. The situation can be different for Snap. Perhaps the format will establish itself in a particular area of application. However, all of the Canonical formats celebrated by the company tie up a lot of resources and then quickly disappear.

Therefore, before accepting claims made about a package system, it is a good idea to figure out how well designed the system is and how it can actually be of benefit. Then, the user is better able to decide whether to relegate the RPM and DEB formats, which have been around for the last 20 years, to the "Old Timers" category and send them out to pasture or whether to keep on using them.

Both of these formats raise the yardstick significantly for competition from alternative possibilities. Even so, using these tools to tease out desired information on package status [5] is often like stumbling around an enchanted garden. In this article, I use the DEB format and selected use examples to show use possibilities that exist once the user leaves the beaten path. All of the examples I present work for Debian, as well as its derivatives, like Ubuntu, Linux Mint, and Armbian.

Software Distribution

Up to now, the concept under Linux has been to disassemble a piece of software component by component and make the individual components available in separate packages. The developer or maintainer specifies information about which packages belong together and then includes it along with the identification of package dependencies in the package description. This makes it possible to have decentralized development. It also makes for optimized use of memory. Duplicates of the components or multiple versions are not an issue. Identical program code can be reused as needed.

Errors that occur in one component, for example in a library, will affect all programs using that particular component. The opposite also holds true. Corrections and cleanups immediately have a positive effect on all components. For the developer, this assumes knowledge of which components are needed and which already exist. Understanding the larger picture beyond the project at hand is always a good idea.

Underlying the "new" developments in container-based package formats is the desire to make software available by means of a concept linked to virtualization. This change of direction has had far reaching consequences that are not always apparent. See the "Changing Software Distribution" box. The real-world parallel is found in the area of throwaway consumer goods. Sustainability works differently.

Proponents of the new developments in software frequently forget that needs surrounding software components change. Change also comes to the components themselves. Therefore, adaptation is essential. Brand new rollouts are not always the best solution. It takes a lot of effort before performing an update to collect, save, and re-install configuration files, as well as user and report data. Fans of the status quo, on the other hand, only switch out what is necessary. Either approach can be appropriate depending on the circumstances. The user will have to decide which choice makes more sense for the situation at hand. There is not one solution for everybody.

Finding the Disc Hog

Disk space can become limited depending on how much software a user loads. The tools dpkg (with the -s option) and dlocate (with the -du option) use the package name to figure out how much space the package requires.

Listing 1 combines dpkg with fgrep , as well as dlocate together with tail and cut , in order to extract just the first column showing the total amount of required space from the last line of the output. By way of example, I show how this works for the chromium package where the output value is displayed in kilobytes. Conversion into megabyte requires some shell scripting and the help of the command-line calculator bc . The echo command causes the unit of measurement to be displayed (next to last line).

$ dpkg -s chromium-browser | fgrep Installed-Size:
Installed-Size: 155388
$ dlocate -du chromium-browser | tail -1 | cut -f1
155464
$ echo $(echo $(dlocate -du chromium-browser | tail -1 | cut -f1) / 1024 | bc) "MByte"
151 MByte

The dpigs ("diskspace pigs") tool from the debian-goodies package helps you find the packages that are taking up the most disk space. Listing 2 lists the five largest packages that have been installed. They appear in descending order by size and name. You can use the -H option to convert the unit of measurement into commonly understood sizes. Entering -n5 lets you limit the output to five packages.

$ dpigs -H -n5
 436.7M texlive-latex-extra-doc
 155.8M linux-image-3.16.0-4-amd64
 151.7M chromium
 120.9M libreoffice-core
 106.8M texlive-pstricks-doc

You use the -Z switch to have the front-end aptitude calculate space requirements for packages that have not yet been installed. The program even takes dependencies into account. The sub-command install used together with the --simulate switch simulates the entire process. Listing 3 shows the output by reference to the corresponding packages for the Nginx web server. If the process needs more packages, then aptitude will show a prompt. Clicking on the N will interrupt the process.

$ aptitude -Z install --simulate nginx
The following NEW packages will be installed:
 nginx <+37.9 kB>  nginx-common{a} <+169 kB>  nginx-core{a} <+1275 kB>
0 packages upgraded, 3 newly installed, 0 to remove and 288 not upgraded.
Need to get 458 kB of archives. After unpacking 1482 kB will be used.
Do you want to continue? [Y/n/?]
Would download/install/remove packages.

Modified Packages

The dlocate and debsums tools make it possible to identify modified files of an installed package. Both tools use the hash function MD5 to compare the files from a Debian package with the files actually found on the disc.

dlocate uses the -md5check switch (Listing 4), but debsums manages without any additional input (Listing 5). Each tool also needs to know the name of the package that you want to monitor. In the example given, this is the interactive load indicator program htop . The OK indication in the output shows that the MD5 value corresponds to that in the Debian package, thus the file has not changed.

$ dlocate -md5check htop
usr/bin/htop: OK
usr/share/applications/htop.desktop: OK
usr/share/doc/htop/AUTHORS: OK
usr/share/doc/htop/README: OK
usr/share/doc/htop/changelog.Debian.gz: OK
usr/share/doc/htop/changelog.gz: OK
usr/share/doc/htop/copyright: OK
usr/share/man/man1/htop.1.gz: OK
usr/share/menu/htop: OK
usr/share/pixmaps/htop.png: OK

$ debsums htop
/usr/bin/htop OK
/usr/share/applications/htop.desktop OK
/usr/share/doc/htop/AUTHORS OK
/usr/share/doc/htop/README OK
/usr/share/doc/htop/changelog.Debian.gz OK
/usr/share/doc/htop/changelog.gz OK
/usr/share/doc/htop/copyright OK
/usr/share/man/man1/htop.1.gz OK
/usr/share/menu/htop OK
/usr/share/pixmaps/htop.png OK

If instead, the goal is simply to find files that are different from the originals, then you can call debsums with the -c switch, the long version of which is --changed . debsums will need superuser rights (sudo ) in order to inspect all of the directories. Listing 6 verifies and lists as missing debsums files from the cupswrapperhl2250dn and hl2250dnlpr files.

# debsums -c
debsums: missing file /usr/local/Brother/Printer/HL2250DN/cupswrapper/brcupsconfig4 (from cupswrapperhl2250dn package)
debsums: missing file /usr/share/doc/hl2250dnlpr/copyright (from hl2250dnlpr package)
debsums: missing file /usr/share/doc/hl2250dnlpr/changelog.Debian.gz (from hl2250dnlpr package)

Modifications and Bugs

The changelog file executes changes that have been made from one package version to the next. Both apt-get and aptitude can use the changelog sub-command, which shows you the changes. Listing 7 demonstrates with excerpts by reference to aptitude and the package smartpm .

$ aptitude changelog smartpm
smart (1.4-2) unstable; urgency=low
 * Switch to dh_python2 (Thanks to Barry Warsaw)
 -- Free Ekanayaka <freee@debian.org> Fri, 12 Aug 2011 17:27:20 +0100
smart (1.4-1) unstable; urgency=low
 * New upstream release
 * Drop several patches (02_fix_fetcher_test, 03_setup,
 06_CVE-2009-3560.patch and 06_CVE-2009-3720.patch) as they were
 all merged upstream
 -- Free Ekanayaka <freee@debian.org> Tue, 31 May 2011 16:04:52 +0200
[...]

apt-listchanges from the package of the same name is similarly helpful. It chimes in along with package management and indicates which modifications existed prior to the installation or update of a package. You can call the tool separately at any time in order to find the information independently of installation and updates.

In Listing 8, apt-listchanges extracts modifications from the DEB package file ruby-json_1.7.3-3_i386.deb in an explicit call. The two tools, popbugs from the debian-goodies package and rc-alert from devscripts , specialize in finding release-critical bugs.

# apt-listchanges -f text --which=both /var/cache/apt/archives/ruby-json_1.7.3-3_i386.deb
Reading Changelogs...
ruby-json (1.7.3-3) unstable; urgency=high
 * set urgency to high, as a security bug is fixed.
 * Add 10-fix-CVE-2013-0269.patch, adapted from upstream to fix denial of
 service and unsafe object creation vulnerability.
 [CVE-2013-0269] (Closes: #700436).
 -- CÈdric Boutillier <cedric.boutillier@gmail.com> Tue, 12 Feb 2013 23:14:48 +0100
[...]

Configuration Files

Many packages contain prepared configuration files. You can display these with dlocate with the -conf option (Listing 9). Further configuration files that are added to the system for a package will however go undetected. dlocate only analyzes the information contained in the original package.

$ dlocate -conf xpdf
/etc/xpdf/xpdfrc
/etc/X11/Xresources/xpdf

Distribution Consistency

APT comes with a small diagnostic tool via apt-get and its sub-command check . The diagnostic tool updates the package buffer and checks whether there are damaged or unfulfilled dependencies on the system. The diagnosis is performed on all of the packages that have been installed, as well as those that have been decompressed but not yet configured. Listing 10 displays diagnosis results with no outstanding issues.

# sudo apt-get check
Reading Package lists... Finished
Building Dependency Tree.
Reading in status information.... Finished

The commands dpkg --audit and apt-cache unmet perform similar operations. The latter displays a summary of all unfulfilled dependencies in the package cache. If you add one or two package names, then apt-cache correspondingly limits the search. For an example of this, see Listing 11, which limits the search to the wireshark package. The output also contains recommendations for packages that have not yet been installed.

$ apt-cache unmet "wireshark*"
Wireshark package Version 1.8.2-5wheezy10 has one unmet dependency:
 Replaces: ethereal (< 1.0.0-3)
Libwireshark2 package Version 1.8.2-5wheezy10 has one unmet dependency:
Replaces: wireshark-common (< 1.4.0~rc2-1)
Libwireshark-data package Version 1.8.2-5wheezy10 has one unmet dependency:
 Replaces: wireshark-common (< 1.4.0~rc2-1)
Wireshark-common package Version 1.8.2-5wheezy10 has one unmet dependency:
Replaces: ethereal-common (< 1.0.0-3)
[...]

Finding New Software

Everybody likes improvements and fresher software. apt-get takes care of this preference with the sub-command upgrade and the -u (short for --show-upgraded ) and -s (short for --simulate ) options. The program executes all of the packages with new versions. You can use the -s switch to check what occurs when the new version is installed (Listing 12).

# apt-get upgrade -u -s
Reading package lists...
Building dependency tree....
Reading in status information....
The following packages are being updated (Upgrade):
 icedove libc-bin libc-dev-bin libc6 libc6-dev libc6-i686 libnss3 libnss3-1d
 linux-headers-3.2.0-4-686-pae linux-headers-3.2.0-4-common
 linux-image-3.2.0-4-686-pae linux-libc-dev virtualbox-guest-source
 virtualbox-ose virtualbox-ose-dkms virtualbox-ose-guest-source
 virtualbox-ose-guest-utils virtualbox-ose-source virtualbox-source
19 updated, 0 newly installed, 0 to remove and 0 not updated.
Inst libc-bin [2.13-38+deb7u1] (2.13-38+deb7u4 Debian-Security:7.0/stable [i386]) [libc6:i386 ]
Conf libc-bin (2.13-38+deb7u4 Debian-Security:7.0/stable [i386]) [libc6:i386 ]
[...]

Alternatively, you can do the same thing with APT and show versions using aptitude search '~U' or – starting with Debian 8 "jessie" – also apt-list .

Up to this point, the process still does not make clear where the package administration actually gets the package. You can figure this out by calling apt-cache policy and apt-cache madison . Listing 13 shows the apt-cache policy and combines the installation status and the located source for the kteatime package. The package that has not yet been installed was transferred from the main distribution area of the German Debian FTP server.

$ apt-cache policy kteatime
kteatime:
 Installed: (none)
 Installation Candidate: 4:4.12.4-1
 Versions table:
 4:4.12.4-1 0
 500 http://ftp.de.debian.org/debian/ jessie/main amd64 Packages

Unlike the above, the sub-command madison browses through all of the existing versions of a package. Listing 14 shows this for the kteatime package where binary and source packages are available.

$ apt-cache madison kteatime
 kteatime | 4:4.12.4-1 | http://ftp.de.debian.org/debian/ jessie/main amd64 Packages
 kteatime | 4:4.12.4-1 | http://ftp.de.debian.org/debian/ jessie/main Sources

Names and Package Description

In addition to the command-line tools (apt , apt-get , apt-cache , aptitude , wajig , and cupt ) and the graphical tools (Synaptic, Muon [6], SmartPM [7], and Apper), searches for software packages and files can also be performed via the web browser. The website for the Debian project [8] (Figure 1) and the APT Browse website [9] (Figure 2) are reliable sources with a wide variety of search possibilities.

Figure 1: Searching for a package on the Debian project website…

Figure 2: … and on the APT Browse website.

Package Dependencies

You can determine how the software packages are coupled by using debtree and apt-rdepends , each of which comes from a package of the same name. Both tools first create a file in DOT format [10] for descriptions of the nodes [11]. The program Dotty from the graphviz package then converts the data into a graphical representation (Figure 3). The calls in Listing 15 illustrate the process using apt-rdepends on the tcpdump package.

Figure 3: Dotty shows the dependencies found for the tcpdump package using the apt-rdepends tool.

$ apt-rdepends -d tcpdump | dot > dump.dot
$ dotty tcpdump.dot

Conclusion

The existing package systems offer a very robust basis for managing software. Consequently these systems are reliable on the server and the desktop. For a better understanding, it is a good idea to take some time to examine this topic. Getting organized always involves a choice between simplicity and stability. Users responsible for system maintenance usually make stability a priority. A computer that works reliably makes for a happy user.