On Tue, 17 Nov 2009 at 12:37:55 +1030, Ron wrote: > This is a known issue, yeah. But I don't really think it's a bug in the > plugin per-se.
I'm not going to get into BTS severity ping-pong, but I don't see how this can
not be grave. dovecot-antispam only has one purpose (being loaded into
dovecot-imapd), but when the current sid/i386 version of dovecot-antispam is
loaded into the current sid/i386 version of dovecot-imapd, it is not only
non-functional, but also prevents IMAP logins. It's only coincidence that the
versions in squeeze don't currently have the same failure mode.
(This gets worse in backports or partial upgrades, since without a dependency
it's unclear whether you're meant to be using the stable or backported version
of dovecot, only one of which can be supported; my interest in this bug
started from upgrading dovecot-antispam on a lenny + backports machine and
breaking its IMAP server.)
> 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.
I've been cc'ing dove...@packages.debian.org on recent mails in this bug;
Dovecot maintainers, any thoughts on this? Bug #456021 "Please use looser
versioning for plugin interface" is very relevant to this, but appears
to have been open for two years with no response, so I'm not holding my
breath...
I believe the patch I provided is the best dovecot-antispam can do to resolve
its current unusability without assistance from the dovecot package. With
this patch it would need a binNMU for each Dovecot upstream release to remain
installable, but at the moment, it needs a binNMU for each Dovecot upstream
release *anyway*, to remain usable (the dependencies just don't make that
obvious).
Having looked at the contents of dovecot-dev, it seems that Dovecot wasn't
really designed to be used with out-of-tree plugins - the fact that dovecot-dev
contains /usr/include/dovecot/src and /usr/include/dovecot/config.h seems to
indicate that plugins are "meant to be" in-tree.
As such, I think the simplest way for dovecot-antispam to remain usable with
dovecot's help would be to embed it in the dovecot package as a Debian patch,
in the same way that it's currently patched to contain a plugin for mbox.gz
and a plugin for IMAP quota?
> > --- 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 ;?
There are two nested /bin/sh processes here: one implicit in $(shell foo)
and one explicitly invoked. I did try to use $(shell sed...) but ran into a
collision between shell-quoting and Makefile-quoting, and chose to go for
robustness over optimization.
> > +# 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
It's the normal autoconf PACKAGE_VERSION, which goes into (among other things)
the name of the tarball, so I would hope that every upstream release would
increment it! This is the same string that Dovecot's plugin-compatibility
check uses, so the plugin will load successfully if and only if the
PACKAGE_VERSION matches.
> 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 ...
A fair point.
Regards,
Simon
signature.asc
Description: Digital signature
