Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
On Tue, 06 Jan 2009, Ian Jackson wrote:
> Raphael Hertzog writes ("Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian"):
> > On Thu, 01 Jan 2009, Joerg Jaspert wrote:
> > > Yet, we do see that there are people who want Qmail, and instead of
> > > maintaining it in an own repository want it in Debian. As it is unlikely
> > > that the positions of the Qmail supporters and us will change soon to
> > > let us find a solution that works for both sides (the positions are
> > > basically black and white here), we ask you to help resolve it,
> > > by a ruling on this matter, following Constitution §6.1.3.
> >
> > What constitutes for you a solution that works for both sides?
>
> I think you have misread Joerg. I did the same at first. Joerg is
> saying that he thinks that there is _not_ any sensible compromise and
> _not_ anything that will work for both sides.
Indeed I did.
> > > - several shortcomings related to the MTA behaviour, including the
> > > backscatter spam issue, failing to use secondary MXs, ignoring
> > > RFC1894, and unbundling of outgoing messages (yay for traffic/resource
> > > waste)[2], thus being unsupportably buggy (Policy 2.2.1)
> >
> > All those are good reasons to not choose the software as a user but not to
> > not include them in Debian. We don't know how our users are going to use
> > it and there might be use cases where those shortcomings are not
> > problematic.
>
> I think this is a dangerous line of argument. Many of Qmail's
> behaviours are terrible in the global Internet and we have no
> effective way to prevent (or even warn) our users from running Qmail
> in that situation.
We do have ways to warn users of the package. We can, for example, add an
annoying debconf note to explain the problems of qmail and point them to
some documentation provided in the package.
> Indeed practically the only reason why people want Qmail is because
> they believe the hype about how ultra secure it is - which is relevant
> (if you believe it) in precisely the circumstances where Qmail's
> problems are most severe.
When Debian was running it on lists.debian.org, it was primarily for
performance reasons IIRC (a listmaster of that time can correct me). It
might be that it's no more the selling factor nowadays, but I find it
presomptuous to believe to know why users are interested in it, without
some more serious study.
> Kalle Kivimaa writes ("Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian"):
> > I think the more abstract question here is:
> >
> > If a software easily causes problems for other machines in a network,
> > should that software be allowed into Debian, even if the software
> > doesn't bring any new functionality?
>
> Yes, I think that's an excellent way to put the question. The answer
> is obviously `no'.
I don't think the answer is so clear cut. "ping -f" can also "easily
causes problems for other machines in a network".
I know we're speaking of the default configuration of a mail daemon
and that the comparison doesn't really hold (although it does with the
phrasing selected).
My main problem is that not including the software in Debian doesn't give
any chance to improve in our infrastructure and that the ftpmasters is not
the right body to decide on the quality of a package (see below), except
for some limited policy compliance check.
> Either steps need to be taken to prevent these problems (for the
> network as a whole, for other parts of Debian who need to interact
> with the package, and for the user who runs it) - or the package
> should not be included.
I can buy this reasoning when it comes to inclusion in a stable release
but not for inclusion in experimental (or sid if the proper RC bugs are
filed immediately).
It's very similar to the reportbug-ng problems that explain that the software
is not part of Lenny.
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
Reply to: