[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#510415: marked as done (tech-ctte: Qmail inclusion (or not) in Debian)

Your message dated Thu, 27 Aug 2009 14:34:16 -0700
with message-id <20090827213416.GD13040@volo.donarmstrong.com>
and subject line Re: Bug#510415: Call for votes on Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
has caused the Debian Bug report #510415,
regarding tech-ctte: Qmail inclusion (or not) in Debian
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
510415: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510415
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: tech-ctte
Severity: normal

Dear Technical committee,

the ftpteam has been thinking about the inclusion of QMail into Debian
for some time already. We feel that qmail, unless heavily patched, is
not a suitable MTA at this time and age. It is plagued by numerous bugs
(or misbehaviours, some might consider them features) and as such, in
our opinion, falls into the category of "so buggy that it is not
supportable", which is not for Debian main (Policy 2.2.1). Also, afawk,
there is no real current Upstream.

For this reason we, the ftpteam, think that QMail is not suited for inclusion
into Debian main.

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.


Criteria for inclusion that qmail meets:
- active maintainer (Gerrit Pape)

- security team willing to support it [1]

- license DFSG compatible


Criteria that speak against inclusion:
- no real upstream

- 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)

- we do have many other, way more modern and better supported,
  MTAs available.

- still, in the reupload after the initial reject[3], seems to violate
  Policy (11.6), for example by not being able to handle etc/aliases
  files as required. Needs yet another package for this.
  Here qmail-run is the MTA provider, yet it doesn't follow the must in
  policy saying "All MTA packages must come with a newaliases program".
  Instead it has a recommends on fastforward, which then provides it.

- Still seems to violate the FHS. /var/lib/qmail/queue belongs into
  /var/spool, as far as we can tell.

- Lots of symlinks in /var/lib/qmail/bin going to /usr/bin/ and/or
  /usr/sbin. This is at least sick, if not again an FHS
  violation. var/lib is for "Variable state information", not binaries
  or links to them.

- qmail-uid-gid is creating users/gids with hardcoded ids in the
  60000-64999 range. While thats allowed from policy, stating "Globally
  allocated by the Debian project, but only created on demand.", wth is
  this global registry, and is qmail registered there?
  Also seems very much 18 century to have such hardcoded lists.

- The already existing (in non-free) qmail-src package only counts
  238 installations, which doesn't seem to imply a large userbase.
  (Of course we don't know how many people have the unofficial netqmail
  packages installed)


[1] http://lists.debian.org/debian-devel/2008/11/msg00618.html
[2] http://www.dt.e-technik.uni-dortmund.de/~ma/qmail-bugs.html
[3] http://lists.debian.org/debian-devel/2008/11/msg00641.html

-- 
bye, Joerg
>Do you agree to uphold the Social Contract and the DFSG in your Debian
>work?
Absolutely.
(does anyone say "no" to this question? :) )

Attachment: pgpXGRc7EDMIE.pgp
Description: PGP signature


--- End Message ---
--- Begin Message --- 
On Thu, 27 Aug 2009, Andreas Barth wrote:
> 34215

With 4 people ranking 3 first, and Steve ranking it second, I believe
the outcome is no longer in doubt, and so the CTTE has resolved that

3. Qmail is to be allowed in to the archive after a patch to resolve
the delayed bounces issue, where mail sent to an invalid recipient
which a reasonable MTA is capable of knowing is invalid is accepted
instead of being rejected at RCPT TO time. After upload, the process
outlined in option #2 will take effect.

[From option #2]

Ftpmaster should perform standard NEW processing for licensing,
copyright, and general packaging issues as normal. with the addition
of an RC bug filed immediately to preventing normal transition for a
period of at least a month after traversing NEW.

During this period, additional RC (or non-RC) bugs should be filed by
interested parties, and updated qmail packages fixing these bugs
should be uploaded as usual. After a month, the RM or the maintainer
can continue to decide that the package is not acceptable for release
at their discretion, as happens for any package. [If the RM or
maintainer don't reaffirm the transition blocking bug, the ctte will
close the transition blocking bug.]

Qmail is subject to the normal removal process for packages.

=====

Assuming I haven't made some mistake, I'm closing this bug. I'll
update the webwml pages and notify the appropriate parties.



Don Armstrong

-- 
The state must declare the child to be the most precious treasure of
the people. As long as the government is perceived as working for the
benefit of the children, the people will happily endure almost any
curtailment of liberty and almost any deprivation.
 -- Adolf Hitler _Mein Kampf_ p403

http://www.donarmstrong.com              http://rzlab.ucr.edu

--- End Message ---
Reply to: