Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Joerg Jaspert writes ("Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian"):
> Criteria that speak against inclusion:
> - no real upstream
I don't think that this is necessarily a showstopper. We have many
important packages in Debian that have defunct or completely absent
upstreams, so that in some cases the Debian maintainer has become de
facto upstream not just for Debian but for many other systems too.
What is required is that _someone_ is able and prepared to act as
upstream. Is Gerrit Pape willing and able to do that ? Does he have
the skills and experience necessary for maintaining an MTA package
written in a somewhat-strange C dialect ? (I haven't looked into this
question but it seems the one we need to ask.)
This may seem like an unfair argument but I think it's valid: I think
that if someone is so keen on Qmail that they want to add it to Debian,
that in itself might well lead us to question their competence to deal
with Internet email systems.
> - 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)
Most of these are IMO release-critical bugs. Qmail's aberrant
behaviours are well-known in the Internet mail community. They are in
many cases gross violations of reasonable and acceptable behaviour and
can cause serious problems for other sites as well as the Qmail
administrator.
So we absolutely MUST NOT provide such a Qmail.
It is possible for a new package with release-critical bugs to belong
in sid. However, this only makes sense as part of a plan to address
these bugs and fix them so that the package can propagate to testing
and only if the bugs are not absolutely hideous (and some of these
are).
Such a plan does not IMO need to be a sure thing, but it needs to have
a reasonable prospect of success. That's very difficult for
deficiences which are built into the design.
So at the minimum I would expect an explanation from the prospective
maintainer. Gerrit, can you supply a list of:
* Every criticism which (otherwise-) reasonable people have
levelled as a serious complaint against Qmail (and I don't
include just the complaints made by the ftpmasters);
* For each such criticism, what your opinion of it is and what
if anything you plan to do about it.
> - still, in the reupload after the initial reject[3], seems to violate
> [etc. etc. -iwj]
More bugs, generally RC IMO. (Although I don't want to go into them
in detail.)
> - we do have many other, way more modern and better supported,
> MTAs available.
>
> - The already existing (in non-free) qmail-src package only counts
> 238 installations, which doesn't seem to imply a large userbase.
These are of course not in themselves reasons not to accept a package,
or at least if they are they are very weak. But it does mean that
there is no need here for thinking very hard about making exceptions
if it seems that Qmail is just too bad.
Ian.
Reply to: