Debian Package Management

Some extracts from the mailing list:

What puzzles me is the relationship between, say, dpkg, dselect, apt, apt-get, aptitude, synaptic, uncle tom cobbley etc.

At the end of the day, everything is basically a layer on top of dpkg - dpkg is the package management system, and the other fluff just makes new packages available in different ways.

dselect and aptitude are very similar tools - menu-based console programs to select things to install. dselect is the "old way", aptitude is the "new way".

apt (which is the name for apt-get and apt-cache) is a command line tool for updating and getting new packages and stuff.

aptitude is generally the preferred tool, though, especially for things like system upgrades where apt can leave your system in "a state", as it were.

synaptic is just a GUI version of aptitude, really, ditto all the other GUI front ends.

Basically, the only tool you really need to know about is aptitude, and maybe apt for strange systems which don't have it installed.

What /is/ a repository?

It's just a filestore with a certain directory layout and some useful indexes. Nothing special.

How do I cope with packages that aren't in a repository, such as the kernel I built, which resulted in a .deb file?

A repository is just somewhere you can grab packages - a CD, a website, whatever. If you already have the package, you don't need a repository unless you need to find other packages to fulfil dependencies.

Your dpkg will hold its own list of packages - those that are installed or were installed on your machine.

Do I need to uninstall before reinstalling my next attempt at building the kernel?

No, not necessarily. If it's the same package (ie., same version of the kernel) it will just replace it (it basically uninstalls and reinstalls for you). If it's a different package (a different version of the kernel), you'll usually find that the two packages can be installed alongside each other, so you can fall back to the older kernel if needed.

Kernel packages tend to be special like this, in that they are named after the kernel version precisely so you can have many different versions installed. Usually, you can't install different versions of a piece of software alongside each other.

I have just started with Debian too, and I have so far used apt-get exclusively. It's working really well, as long as you know what the package you want is called. comes in very handy.

apt-cache is the companion tool to apt-get for examining the package database. Specifically "apt-cache search foo" searches the database for foo and "apt-cache show bar" displays information about package bar.

If we want to set up several systems, for example at a group meeting, presumably it would be a lot faster to have a local repository? Or is that idea a nonsense -- would it be more sensible to have some kind of caching proxy instead?

Caching proxy makes much more sense. There are a huge number of ways of doing this, including apt-specific software like apt-catcher.

I've had a fair amount of success with apt-cacher, and can recommend it for anyone updating multiple machines. I've also used apt-proxy, but didn't like it.

There are tools for doing a mirror of a repository (eg. debmirror). Be warned that a full debian mirror is BIG (several Gb per architecture).