I guess I should’ve actually reported the lintian bug rather than just ignoring the bogus warning.

• 532 depend on zlib1g 1:1.2.3.3.dfsg-1, the version which introduced support for _FILE_OFFSET_BITS=64 and the version which packages that were built before zlib1g had symbol version information will depend on.
• 333 depend on version 1:1.2.1, which predates sarge let alone etch.
• 74 depend on the even earlier version 1:1.1.4-1.
• 843 packages have an unversioned dependency on zlib1g – a quick glance at some of these indicates that (as I would expect) they either don’t actually link against zlib directly or do but don’t use any symbols from it.
• The remaining two packages are the -dev and -dbg packages which have an exact dependency on the library package they were built against.

Of course, zlib is a particularly good use case for this – both API and ABI are extremely stable and most of the changes in interface are in rarely used features – but it’s still good to see it working in practice. I don’t need to worry nearly so much as I would have done previously about keeping other packages out of testing.

If you maintain a library written in C I would encourage you to take a look at implementing this, it’s very straightforward. Libraries written in other languages may cause more difficulty. There are some automatically generated symbol files in mole which provide a good starting point (I didn’t use them since upstream already had a more exact list of versions at which symbols were introduced) and support is already present in debhelper. The main things to watch out for when using the mole data are backwards compatible ABI changes which don’t just add new symbols (for example, if new values are accepted by a function) and variations between architectures.

Kudos to Raphaël for all the work he’s put into this.

Unfortunately I can’t actually remember the numbers they came up with but perhaps someone could enlighten us.

It looks like we may well continue to make progress with this thanks to proposals like having Debian Maintainers as well as developers – another iteration of ideas like sponsorship which was originally developed to work around a process problem that people were seeing at the time with NM.

This makes me all the more happy to see something like the Smith review project ticking away. It’s all being done on the basis of “Hey, this seems like a good idea – anyone object or want to help?” and by the time it’s done it will have touched every package in Debian which is getting on for as ambitious as it’s possible to be. So far it seems to be getting positive responses from maintainers – I’m sure there will be problems somewhere along the line but I’d be surprised if they were anything other than a tiny minority.

Doing this is no substitute for getting patches submitted properly with good documentation and extraneous changes stripped out. Personally I have always been fortunate in the people working on my packages in Ubuntu – I’ve almost always found that the changes that are applicable to Debian have been sent to me already by the person making them. I’d go so far as to say that most of the substantial patches I’m given come from Ubuntu developers. In the one case this hadn’t happened the person making the change was surprised and apologized that they’d forgotten.

In order to avoid these problems the version of NIS in etch disables Network Manager support by default but the configuration file with this change is not updated automatically on upgrade. To disable Network Manager support by hand edit the configuration file /etc/default/nis to add -no-dbus to YPBINDARGS:

# Additional options to be given to ypbind when it is started.
YPBINDARGS=-no-dbus


Uninstalling the network-manager package if it is not in use will also resolve the problem.

This also applies to the packages currently scheduled for release in the next version of Ubuntu (codenamed Feisty).

deb http://ftp.debian.org/debian/ experimental main
deb-src http://ftp.debian.org/debian/ experimental main

(or use a mirror) and edit /etc/apt/preferences to tell apt to install Leafnode from experimental:

Package: leafnode
Pin: release a=experimental
Pin-Priority: 500

and install or upgrade Leafnode as normal.

It should be possible to upgrade directly from Leafnode 1 (please file a bug if this is not the case) but please note that due to incompatible changes in the news spool format once Leafnode 2 has been installed you will have to purge Leafnode before downgrading to Leafnode 1.

As far as I have noticed m68k doesn’t tend to have many porting issues that require fixes in individual packages beyond the toolchain and kernel – if that is the case it’s a bit of a moot issue.