Bug#457318: qmail and related packages in NEW
On 11583 March 1977, Gerrit Pape wrote:
As i got asked for the complete text of the rejection mail, as the
thread start only had a partial quote, here it is.
--8<------------------------schnipp------------------------->8---
From: Joerg Jaspert <ftpmaster@debian.org>
Subject: netqmail_1.06-1_powerpc.changes REJECTED
To: Gerrit Pape <pape@smarden.org>
Cc: Debian Installer <installer@ftp-master.debian.org>
Date: Sun, 06 Jul 2008 16:19:30 +0200
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
archive:
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:
qmail-uids-gids
* 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
qmail
* 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:
#!/bin/sh
cat >&2 <<EOT
qmail on Debian by default doesn't support the /etc/aliases database,
but handles mail aliases differently, please see
http://lifewithqmail.org/lwq.html#aliases
EOT
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
members.
--8<------------------------schnapp------------------------->8---
--
bye, Joerg
[...]that almost anything related to "intellectual property" is idiotic
by it's nature, [...]
Reply to: