package alternatives - dependency spaghetti

GNU/Linux systems and similar have several package management systems, most of which do a good job.

deb and rpm packages work well, provided dependencies are crafted carefully, to avoid

dependency spaghetti (or dependency hell)

I have run Debian production systems for 7 years or so, and I rarely see aptitude struggle to find a good solution.

Right now I am testing out the latest Debian (Squeeze), and it provides an example, that I have worked through on one system, and want to document here.

During testing, I noticed that my file manager Thunar was not automatically picking up changes to the underlying directory.

File alteration monitors (fam or gamin) generally look after this functionality.

Currently the system is using fam and here is a summary from dpkg:

which says that fam rather than gamin is providing the alteration monitor for my system.

Now the logical thing to do I thought would be to switch to gamin and see if that fixed my issue (described in paragraph 4)

Here aptitude tells me that Thunar recommends gamin:

Here is a screenshot of what aptitude thinks of my attempt to switch away from using fam:

Now removing libfam0 seems like the logical thing to do...

...but a quick look at the dependencies for libfam0, caused me a moment of pause:

And the way to reassure yourself is to preview the changes after choosing (!: Apply):

The output from aptitude includes the phrase 'removing anyway as you requested', which has me wondering?

Now a dpkg summary shows my system having gamin installed rather than fam:

The key to understanding how and why this works is to realise that, in Debian Squeeze, libgamin0 has been marked as a drop in replacement for libfam0 as shown here:

Which means that you can ignore any 'removing anyway as you requested' messages, and know that your system, has not been broken by your actions.

My system has no Nautilus file manager but instead uses Thunar:

...and as thunar recommends gamin, it is a shame that gamin, rather than fam, was not on my system automatically.

Now to see if my file manager is picking up changes to the underlying files in realtime :)

Debian Squeeze - packages 'held back'

During the 'testing' phase of a Debian distribution, it is expected that you will encounter packages being 'held back' a little more frequently.

Running a stable distribution you should mostly only see 'held back' for packages which you have deliberately put on hold.

Right now Debian Squeeze is a 'testing' distribution and this has provided my example for this article.

ntpdate on Debian (which I have installed):

There are several tools for synchronising dates of your server with external clocks.
Ntpdate is one such tool, openntpd and chrony are some alternatives.

ntpdate on my system shows as being 'held back' and I explain why below.

and running dist-upgrade gives similar results:

Now at this point you can check if perhaps you deliberately placed this package on hold by typing:

aptitude search ~ahold

The last portion spaced out is tilde then a then hold
  ( hold is the action flag you are searching for )

Which on my system gave no results ( meaning I have not placed ntpdate on hold )




So what is causing my system to say ntpdate is 'held back'?

Debian package tools are fairly well behaved and will not remove packages without some intervention from yourself.

You have to instruct Debian to remove dhcp3-client and until you do then ntpdate will be 'held back'.

Knowing this server as I do, I am fairly sure that dhcp3-client is something i do not need to keep, however there is no harm in checking if anything else will be affected.

Here there is a lot of information and you can treat as less important the lines beginning with pipe (|) which are merely 'suggests'.

   ( The non piped lines are a mixture of 'depends' and 'recommends' )

Here is a graphical representation (feel free to skip the graphics if you like)

Using the --installed flag to apt-cache rdepends gives you the most important information specific to your system.

What the above tells me is that ntpdate depends on dhcp3-client and ifupdown 'suggests' dhcp3-client. My final check was that I did in fact have ifupdown installed - yes it is installed on my system.

And the nugget of this article is really how to get apt past this 'held back' situation as shown here:

So if you have a 'held back' package, and you are certain that you are okay with what apt is going to remove, then go ahead and execute...

apt-get install packagename

( where packagename is replaced by the name of your particular package )

Note: Had my system really had a need for dhcp3-client ( certainly some desktop systems make use of this package ), then I would not have proceeded, and would have considered the following options:

1. Find an alternative to ntpdate
2. Find an alternative to dhcp3-client
3. Wait a while to see if the situation fixes itself*

*As explained at the outset of this article, I am running Debian Squeeze during it's testing phase and packages and interdependencies do change fairly regularly.

For those you are interested in alternatives to ntpdate, and where ntp/ntpdate fit into the grand scheme of things, here are some extra (optional) graphics

     ...and more generally chrony, openntpd, ntpdate (below) ...

Links and further reading:

• The package aptitude-doc-en has great html documentation describing things like 'action flags' and their meaning.
• ntpdate and ntp are different packages. Ntp is for those who want a running daemon rather than just a cli tool for crontab entry happiness.
• This mailing list entry is several years old but provides some very relevant information.