severity 544588 important thanks
Hi Simon, This is a known issue, yeah. But I don't really think it's a bug in the plugin per-se. Dovecot itself really needs a saner way to indicate when its plugin ABI has actually changed than just enforcing they are used with the 'current version'. I've talked to Jaldhar about this previously and he seemed to indicate that this would get sorted out, but I'm still not exactly sure when or how. If you have some time to spend on this, you might like to engage the Dovecot upstream about it (they are generally very responsive). I'd much rather get this sorted out cleanly than create a snarl of overly tight deps that may mean nothing will ever migrate without pain to several parties. But I agree the current situation is far from optimal, and this is an important issue to resolve as soon as we can. Re the patch you attached: > +++ b/debian/get-dovecot-version.sh > @@ -0,0 +1,3 @@ > +#!/bin/sh > +exec sed -n -e 's/#define PACKAGE_VERSION *"\(.*\)"/\1/p' \ > + /usr/include/dovecot/config.h > diff --git a/debian/rules b/debian/rules > index 0ac5356..cbc9d17 100755 > --- a/debian/rules > +++ b/debian/rules > @@ -1,5 +1,13 @@ > #!/usr/bin/make -f > > +EPOCH := 1: > +DOVECOT_VERSION := $(shell sh $(CURDIR)/debian/get-dovecot-version.sh) Uh, are you sure you really need this many subshells to do this ;? > +# if we were compiled against (for instance) dovecot 1.2.7, depend on > versions > +# "1.2.7" <= v < "1.2.7.", so a hypothetical upstream point release 1.2.7.1 > +# would not be considered suitable, ... when in reality, it actually most probably would be perfectly ok. and hypothetically it may not have even had the PACKAGE_VERSION macro that you check incremented -- in which case this would make it impossible for the package to work with that version at all. Even if it was rebuilt. Which is hardly an improvement on the current situation. And keeps getting worse if Jaldhar ever has to release a .dfsg upstream version or so, since again the package version and what you grep out of dovecot source here won't actually match at all ... > +DOVECOT_DEPENDENCY := dovecot-imapd (>= $(EPOCH)$(DOVECOT_VERSION)), > dovecot-imapd (<< $(EPOCH)$(DOVECOT_VERSION).) > + > build: build-stamp > > build-stamp: > @@ -36,7 +44,7 @@ binary-arch: build install > dh_fixperms > dh_installdeb > dh_shlibdeps > - dh_gencontrol > + dh_gencontrol -- -Vdovecot:Depends="$(DOVECOT_DEPENDENCY)" > dh_md5sums > dh_builddeb ... so this is really something that the dovecot(-dev) package should be providing us, with the version(s) that _it_ thinks we should be using. Not something we should be hacking up on a per-plugin basis, based on hypothetical speculation about what may or may not be compatible in the future, in a package we don't directly control. If dovecot-dev provides something like that and it's sane, then I'll be happy to use it here, but I'm a bit uncomfortable about the fix proposed above. It doesn't seem any less prone to horrible failures on the whole, it just changes the flavour of them a little and adds some new failure modes that we don't currently suffer from. We need to bite the bullet and fix this properly in dovecot, anything else will mostly just be a recurring waste of people's time until we do. Cheers, Ron -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
