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

Re: Qmail blocked once again - this time by the FTP masters

On 11439 March 1977, Delian Krustev wrote:

> Gerrit seemed to be ready with his work and has uploaded Qmail in the new 
> queue around April 28th, 2008. Unfortunately his packages are stuck there and 
> the FTP masters seem to be unresponsive ( See the last posts in [5] ).

Wrong, its not stuck, its rejected. please check the facts before you
waste other peoples time with such a mail, thanks. Especially leader@
and also debian-publicity are *the* *wrong* place for it.

Hi Maintainer,

rejected, for various reasons (this mail applies to all of the various
qmail and qmail related packages currently in NEW, namely
netqmail, qmail-run, qmail-tools, dot-forward, fastforward).

First - the packaging is nowhere near the standard Debian aspires to in the

Qmail is an MTA and as such should follow Debian Policy (for example Section
11.6).  It's therefore not a very good start that an MTA package needs
additional packages (qmail-run) installed to perform the minimal tasks
required of mail-transport-agent, and yet another package (fastforward) to
support /etc/aliases.

Now, looking into the binary packages provided by netqmail there are a
*few* points to list:

  * Uses addgroup in preinst without a pre-depends
  * Uses useradd instead of adduser (policy 9.2.2)
  * Why install the uids/gids in preinst?
  * User interaction without using debconf (policy 3.9.1) in both preinst and
    postrm (ok, it's just giving info, but still)
  * Aborts in preinst if:
    - "Upgrading" from a pre 1.06 version (presumably unofficial)
    - UIDs / GIDs aren't what it expects (as the qmail binary then uses these
      UIDs *it* can't be installed without the UIDs being right, but why does
      qmail-uids-gids fail?)
  * Recommends manual use of userdel and groupdel rather than deluser /
    delgroup in postrm 

  * Installs /var/lib/qmail with alias, bin, boot, queue directories
    - Also:
      + users symlink to /etc/qmail/users/
      + control symlink to /etc/qmail/
      + doc symlink to /usr/share/doc/qmail/
    - bin/ contains mostly symlinks back to /usr/bin and /usr/sbin but
      one binary is present (config-fast)
    - boot/ contains what looks like scripts (should probably be in
      /usr/lib/qmail with a symlink if necessary)
    - queue/ is basically the only part which any sane MTA would have in /var

 * Preinst fails if attempting an upgrade from < 1.06 (presumably unofficial)
 * Aborts in postinst if system doesn't have FQDN

Looking at qmail-run there is also:
 * README recommends manually installing non FHS compliant symlinks:
   ln -s /var/lib/qmail /var/qmail
   ln -s /etc/service /service
   Not a policy bug, but certainly in bad taste...
 * C/R/Ps mail-transport-agent
   - Now, this does provide /usr/{sbin,lib}/sendmail
   - But as for /etc/aliases, /usr/sbin/newaliases is:

cat >&2 <<EOT

qmail on Debian by default doesn't support the /etc/aliases database,
but handles mail aliases differently, please see

exit 1

   which breaks policy 11.6
 * Why is qmailctl in /usr/bin?
 * preinst break on upgrades *AGAIN*
 * postinst errors if no FQDN
 * No man pages:

 ---- lintian check for qmail-run_2.0.0_all.deb ----
W: qmail-run: binary-without-manpage usr/sbin/mailq
W: qmail-run: binary-without-manpage usr/sbin/newaliases
W: qmail-run: binary-without-manpage usr/bin/qmailctl
W: qmail-run: binary-without-manpage usr/sbin/sendmail

dot-forward only has
 * Lots of code duplication from netqmail in the supporting code (alloc
   routines etc).  Apparently djb hasn't heard of libraries.

And finally qmail-tools:
 * Native tarball contains upstream tarball for queue_repair.py
 * Package mainly to help with upgrading from non-free / unofficial packages,
   but the scripts just state that it isn't supported...
 * So only use is queue_repair.py; why native?
 * /usr/sbin/queue_repair is a horribly generic name

Aside from these technical - and possibly fixable - problems, we (as in the
ftpteam) have discussed the issue, and we are all of the opinion that qmail
should die, and not receive support from Debian. As such we *STRONGLY*
ask you to reconsider uploading those packages.

Qmail is dead upstream and requires a whole set of patches to even begin to
work in the manner expected of a modern MTA.  Given this, the fact that this
means there is also no upstream security support, and the fact that Debian
already contains at least three reasonable MTAs, we see no need to add qmail to
the archive. So - please reconsider if it really helps Debian to have those
packages. Also feel free to start a public discussion on
debian-devel@lists.debian.org about the issue, including any relevant
information from this email, in order to gather opinions from other project

bye Joerg


If you don't understand why your files were rejected, or if the
override file requires editing, reply to this email.

bye, Joerg
<exa> look i can't afford to to any more work without becoming a DD

Reply to: