Open Source @ Consolidated Braincells Inc.
This is a weblog I'm keeping about my work on Debian and any other useful Debian related info I come across. It is not meant to compete with other news sources like Debian Weekly News or Debian Planet. Mostly it is just a way for me to classify and remember all the random bits of information that I have floating around me. I thought maybe by using a blog it could be of some use to others too. Btw. "I" refers to Jaldhar H. Vyas, Debian developer for over 8 years. If you want to know more about me, my home page is here.
The name? Debain is a very common misspelling of Debian and la salle de bains means bathroom in French.
If you have a comment to make on something you read here, feel free to write to me at jaldhar@debian.org.
You can get an rss 0.91 feed of the blog here.
I am pleased to announce that Marco Nenciarini has joined the Dovecot maintainer team. One of his first contributions was converting the package to the 3.0 (quilt) source format which all the cool kids are doing these days.
One ongoing problem we have is that Dovecot does not (yet) have a stable ABI for plugins. This affects dovecot-antispam as described in bug #544588 The short term solution is binNMUs but obviously a better long term solution is needed. One idea I've had is to include dovecot-antispam as an additional tarball within the dovecot source package now that 3.0 (quilt) gives us that capability. This way, dovecot-antispam will be rebuilt (with the right dependencies) whenever dovecot is. I have previously experimented with multiple tarballs and it works although at the moment all the debian build tools (devscripts, *-buildpackage etc.) don't fully support it. I expect that will be rectified soon enough but there is a philosophical issue as well. dovecot and dovecot-antispam though related, are two seperate upstream projects with seperate versioning, maintainers etc. Does it make sense to lump them together? I say yes; conceptually they belong together. (dovecot-antispam is useless except as a dovecot plugin.) In fact we have many source packages like this, that only exist as workarounds for a flaw—the lack of source dependencies in the packaging system. However when I brought this up on IRC, there was some disagreement.
So I put it to this august assembly, should source packages combine related but distinct upstream sources or not?