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.

Standard exit codes - shell scripts versus binaries

This short article is prompted by the question "What return codes should I use in my shell script?"

Some Answers:

• A non-zero value
• A non-zero value in the ranges 1 through 127 and 138 through 255
• A non-zero value in the ranges 1 through 63, 79 through 127, and 138 through 255

The first answer is certainly correct.

The remaining answers are really a matter of personal preference.

Exit codes 128 through 137:

If a process is terminated by a signal then the standard behaviour is to take the numeric value of the signal, add 128, and use that value as exit code.

128+SIGNAL

So kill -9 someprocess should in theory see the process exit with code 137

There are more than 9 signal codes so you could, if you wish, avoid some of the codes 138 onwards to be absolutely sure.

( Avoiding 128 through 159 might be your preference )

The signal codes for Linux are described here.

Exit codes 64 through 78:

From the Linux exit manpage at kernel.org:

BSD has attempted to standardize exit codes; see the file <sysexits.h>

The actual meanings of the codes are given in this OpenBSD page, but I reproduce the first (64) and last (78) directly give you a flavour:

• EX_USAGE (64) The command was used incorrectly, e.g., with the wrong number of arguments, a bad flag, a bad syntax in a parameter, or whatever.
• EX_CONFIG (78) Something was found in an unconfigured or misconfigured state.

Shell script return codes - my personal suggestion:

Have a quick look through the OpenBSD range 64 to 78 and find something suitable. Then add 100 to that code.

First Example (code 175):

75 in OpenBSD says:

Temporary failure, indicating something that is not really an error. In sendmail, this means that a mailer (e.g.) could not create a connection, and the request should be reattempted later.

( Now adding 100 give 175 which I use )

Second Example (code 178):

78 in OpenBSD says:

Something was found in an unconfigured or misconfigured state.

( Now adding 100 gives 178 which I use )

The bash scripting guide notes (tldp.org):

Appendix D gives some guidance about exit codes.

Linux documentation of sysexits.h (permission of BSD):

#define EX__BASE 64 /* base value for error messages */
#define EX_USAGE 64 /* command line usage error */
#define EX_DATAERR 65 /* data format error */
#define EX_NOINPUT 66 /* cannot open input */
#define EX_NOUSER 67 /* addressee unknown */
#define EX_NOHOST 68 /* host name unknown */
#define EX_UNAVAILABLE 69 /* service unavailable */
#define EX_SOFTWARE 70 /* internal software error */
#define EX_OSERR 71 /* system error (e.g., can't fork) */
#define EX_OSFILE 72 /* critical OS file missing */
#define EX_CANTCREAT 73 /* can't create (user) output file */
#define EX_IOERR 74 /* input/output error */
#define EX_TEMPFAIL 75 /* temp failure; user is invited to retry */
#define EX_PROTOCOL 76 /* remote error in protocol */
#define EX_NOPERM 77 /* permission denied */
#define EX_CONFIG 78 /* configuration error */
#define EX__MAX 78 /* maximum listed value */ 

If you have the Linux source installed then the file /usr/include/sysexits.h contains the text pasted above.