The story of speex/vorbis-tools, or how not to be disservicing to our users
[I'm sending this to three lists. Please only reply to -devel unless
the answer is on-topic for some of the others.]
This mail is about making people aware of how actions aimed at
improving Debian, like providing a new version of a library or NMUing
a package, can have negative effects too, and how can everybody (even
the casual -devel reader) help to minimize such effects.
For that, I will use what recently happened with vorbis-tools and
speex as a example. This is not a personal rant, since I don't use any
of the affected software, but I do care about the overall quality of
Debian and seeing this things happen saddens me a lot. Which is why I
decided to write this e-mail.
None of this is about finding out who was at fault, since we all make
mistakes. It's just about answering "what can I do better", which I
think everybody asks themselves from time to time.
* * *
The Speex library made, among others, the following change between 1.0
and 1.1: its speex.h file moved from /usr/include to /usr/include/speex.
After libspeex 1.1 had been uploaded, a new upload of the vorbis-tools
package happened (an authorized NMU, to be precise). When this new
version was compiled against speex 1.1, the ./configure script failed
to detect the availability of speex, and thus disabled speex support.
A bug about ogg123 not being able to reproduce .spx files any more was
filed at severity important 9 days after the upload (#306809). One
month later, a message was sent to d-devel  explaining the
situation. I read the message a couple days later, and promptly
uploaded a NMU to fix (with maintainer's permission). Unfortunately,
it was too late for it to be included in Sarge.
Net result: ogg123 as shipped in Sarge can't play speex files, while
the software is capable of doing so and so was the case during most of
the Sarge development cycle.
* * *
So let's have a look from several point of views at what can be done
better in order to prevent things like this happening,
Please treat the maintainers of packages build-depending on your
library as first-class users. Try to always be aware of what
consequences will your acts have for them, and communicate when
For example, for the above change between speex 1.0 and 1.1, a
notice could have been sent (and perhaps it was) to the affected
maintainers making them aware of the issue. Such notice is best sent
in the form of a bug in the BTS, so that other people (e.g., NMUers)
can know about the issue too.
If you're certain that the issue will bite a package in the next
upload, file the bug at severity important or higher. For example:
"vorbis-tools: auto-detection of libspeex will fail in the next
Coordinate with the Release Team.
Try to make your build system as robust and deterministic as
possible, as in, avoid if possible that it produces different
binaries for different sets of installed packages. For example,
explicitly using --with-something will make ./configure fail if it
can't find it, while not specifying it would just result on the
script disabling that part.
Know the output of your ./configure script, and baby-sit new builds
looking for differences. Even better, use the resulting config.h file:
always compare the new one with the previous one. Consider putting it
in the source package, e.g. debian/config.h.prev, so that NMUers can
benefit from it too. (I don't think this has been proposed before, and
makes absolute sense to me.)
Inactive package maintainers
Know your limitations, and file RFH/RFA/O bugs as appropriate. Just
welcoming NMUs is not enough, since then you rely on the MIA people
discovering someday that your package is unmaintained.
Read the whole list of bugs for the package before you upload, not
only the ones you'll be fixing. See above under "Library maintainers"
for an example of this being useful.
Subscribe to the PTS of the package. This way, you'll become aware
of any new bugs you've accidentally introduced (as the mentioned
Run debdiff. Twice.
The casual -devel reader
If you see a message about an important issue not being handled, try
to do something about it. Think whom could you forward it to: the
maintainer, the latest uploaders, the maintainers of related
packages, an specific mailing list or IRC channel. It's all about
finding a developer that will care.
If you know that a maintainer is inactive, inform email@example.com.
If he's not inactive, but he's not maintaining a certain package
anymore, politely ask him to consider filing a RFH/RFA/O bug for it.
* * *
And that was all. Thanks for reading and happy hacking.
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
Listening to: Ellos - Muy pequeño
In my opinion, the most fruitful and natural play of the mind is in
conversation. I find it sweeter than any other action in life; and if I
were forced to choose, I think I would rather lose my sight than my
hearing and voice.
-- Michel de Montaigne