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.
As there are no better ideas, today I'm going to split up the dovecot package into 4 pieces. Here is the background. Dovecot is an IMAP server that like all IMAP servers listens on port 143 (or 993 for IMAP over SSL.) This means in Debian package dependency terms that dovecot must 'Provide:' the virtual package imap-server. It also needs to 'Conflict:' with imap-server because only one daemon can have the port. Now it has gained a POP3 server component. So it also has to provide and conflict with pop3-server for the same reason. The thing is it is possible that a user may want the IMAP server but turn off the POP3 server and use, say, qpopper instead. But he can't install qpopper because it also provides pop3-server which conflicts with dovecot. The only solution is to split it into dovecot-imap and dovecot-pop3 with dovecot-common for the shared bits. The fourth package called dovecot is simply a dummy which installs dovecot-imap to allow smooth upgrades. This is one area where Gentoo has us beat at the moment. I don't know if there is an ebuild for dovecot but theoretically they can specify "give me just the IMAP piece not the POP3" in some configuration somewhere. It will be interesting to see if Debian can come up with some solution to this. Having lots of little packages around is icky. The dummy package could be avoided by having dpkg use a field called 'Replacement-for:' or similiar (not 'Replaces:' which is something else.) IIRC, this idea was suggested before but no one ever implemented it.