Packages

Repositories

What are all these entries in “Software Sources”? What do the lines mean in /etc/apt/sources.list?

Well, you got repositories and components. The repositories are (I’m stealing from here):

  • $release: Don’t touch it, I like consistency, even with my bugs.
  • $release-security: I’ll accept patches to existing versions (and very rare version upgrades if absolutely necessary) in the process of keeping my system secure.
  • $release-updates: Okay, some bugs are worth fixing, and I trust you this much (holds up two fingers like Maxwell Smart).
  • $release-backports: I have something akin to technology ADHD, needing the latest of everything I can possibly get, but I can’t handle running the development branch.
  • $devel: I can take it. Seriously. If you break my X, I shall become more powerful than you could possibly imagine. I’ll file and maybe even fix the bugs and I’ll do it even if power management is not so much ‘managed’ as vomited all over the wall. Come get some.
  • Debian: We do the work so you don’t have to.

For example, running aptitude search ~i~Ahardy-backports will show you installed packages from the backports repository.

Then you have 4 components:

  • main: free software, fully supported by Ubuntu
  • restricted: non-free, critical software (usually drivers), supported by Ubuntu
  • universe: free software, not fully supported by Ubuntu
  • multiverse: non-free, non-critical software, not supported by Ubuntu

For example, running aptitude search ~i~srestricted will show you installed packages from the “restricted” component.

Package States

The 1st character is the package’s current state:

  • i means installed
  • p means purged (never installed, or completely removed)
  • c means the package was removed, but not purged (the configuration files were left in the system)
  • v means virtual

The 2nd character is the stored action:

  • pi means the package is purged but is going to be installed
  • A means the package was automatically installed

More information here.

Package Dependencies

Packages have dependencies with other packages in the following forms:

  • depends: these packages need to be there; if not, they will be installed
  • suggests:
  • recommends:
  • conflicts:
  • replaces:
  • provides:

Settings for suggests and recommends should be sitting in /etc/apt/apt.conf or ~/.aptitude/config, but the first file doesn’t exist and the second is empty…

To see the configuration of APT, type apt-config dump.

Package Management Tools

What a mess! on a debian/ubuntu system you have:

  • GUI: synaptic and update-manager
  • Ncurses: aptitude
  • Command-line: apt-get, apt-cache, apt-cdrom, apt-key, apt-ftparchive, apt-url, …
  • Basic: dpkg, dselect, deborphan

And that’s just for the Debian family. The RedHat family use the rpm package manager, with various available frontends (up2date, yum, synaptic on PClinuxOS, yast on Suse, urpmi and rpmdrake on Mandriva), while there’s actually 2 different versions of RPM, both calling themselves “the official one”.

Why can’t we all live happily together?

Documentation

I installed apt-howto and apt-doc to get some insight. Now I have:

  • /usr/share/doc/Debian/apt-howto/apt-howto.en.html is the APT Howto
  • /usr/share/aptitude/README is the aptitude user’s manual
  • /usr/share/doc/apt-doc/guide.html/index.html is the APT user’s guide

Package info

Each package puts 5 files under /var/lib/dpkg/info:

  1. .list: lists the files/directories created due to the package’s installation
  2. md5sims: md5 sums for the new files
  3. postinst: script to execute after installation
  4. postrm: script to execute after removal
  5. shlibs: required shared libraries

Leave a Reply