On Tue, Nov 17, 2009 at 11:16:37AM +0000, Simon McVittie wrote:
> 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.
important
a bug which has a major effect on the usability of a package,
without rendering it completely unusable to everyone.
Tick.
grave
makes the package in question unusable or mostly so, or causes data loss,
or introduces a security hole allowing access to the accounts of users who
use the package.
I'm using it right now. So are you and many others. I'm not aware of it
ever losing data, and this isn't a security issue. That doesn't leave much
to tick there.
> 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.
So if Jaldhar uploaded a new dovecot to sid and didn't request a binNMU,
then request one. This package doesn't need to be modified to fix that,
and the simple matter of fact right now is that it _can't be_.
If there is a handwaving end-of-the-world bug here, it's in dovecot, not
this package.
> It's only coincidence that the versions in squeeze don't currently have the
> same failure mode.
No, it would be a coincidence if I'd uploaded some random version that wasn't
at all built with the version in squeeze. What you mean to say is that it's
a problem that things have gotten out of sync again since then.
I've told you it's a known problem. It's in fact the very problem that led
me to adopt the package in the first place. But we still don't have a good
solution and there isn't one that will fit in this package alone. We need
support from the dovecot package.
> (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.)
It's only a coincidence that backports ever work. They aren't supported
distro releases, and the project hasn't tested them like we do stable
release candidates. If things break when you do them, then you have to
fix them. That's why they aren't automatic...
> I believe the patch I provided is the best dovecot-antispam can do to resolve
> its current unusability without assistance from the dovecot package.
And I believe it's still not even close to good enough, and may well cause
worse problems than it solves. Else I'd have kludged something like this
into it already. I talked about it with Jaldhar, and no clear workaround
of this nature seemed to really suffice.
> 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).
So no real gain. Only the potential for additional breakage ...
and perhaps actually grave bugs.
> 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?
That would be up to Jaldhar. If he wants to do that I'll gladly hand it
over to him. But if that's your next best solution, then this really needs
to be incorporated into _upstream_ dovecot. Not kludged by every distro.
If dovecot doesn't want them all in its tree, then it needs to support this.
I currently don't know if the reasons for not supporting that are technical,
or if just no one has made a sane proposal to fix it and followed that up
with a patch.
> > > --- 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.
I'm pretty sure you can call sed from makefiles... people have done it once
or twice before... and if 'robustness' was the goal, why did you hardcode
the epoch? (Since you weren't optimising, I'll overlook the use of CURDIR ;)
> > > +# 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!
You talked about a hypothetical 1.2.7.1, so we have no idea what it might
really contain, or whether they'd actually bump the internal package version
for it. You're probably right (it's your hypothetical after all ;)
But that won't help people the day you are not. And there are still plenty
of other ways for this to get out of sync.
Anyhow, if you're concerned about the 'graveness' of sid, get a binNMU
scheduled for it. But if we want to really fix the important bug here,
(and I do), that's going to take more than just slapping some more
restrictive deps on it, that we invented out of 'thin air'.
Fixing that is what we need to track in the BTS, and IMO what this bug is
about. So I'm matching the severity to that, not to that sid needs a
binNMU today, because that won't close this either. You can open a new bug
for that issue if you really like, but you'll just have to close it again
manually when the binNMU happens ... else you'll block your own binNMU
from migrating to testing, and it's not going to block this one as it's
already in there...
Even if I applied your patch, this bug would still exist, and it would
still be important. You'd have just hidden that from people under one
more layer of fragile workarounds. I don't think that's the direction
we really want to go with this one, and I don't intend to declare this
'closed' on the basis of "we swept it under the rug a bit further".
So far I've presumed the people who needed to have known about it and
it would get fixed when the time was right for that. Now that we've
got a public report in the BTS, it shouldn't mislead people about the
actual progress being made toward fixing it by getting closed at the
first half-workaround.
Sorry,
Ron
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
