Bug#457318: netqmail_1.06-1_powerpc.changes REJECTED
On Sun, Jul 06, 2008 at 02:19:30PM +0000, Joerg Jaspert wrote:
> 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).
Hi ftpmaster, I had some problems separating the items that are reasons
to reject the packages from other comments about the packaging in
general, and the upstream software. The netqmail, qmail-run, and
fastforward packages have been updated to address the issues, and all
packages are re-uploaded.
> 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.
Hmm, the MTA package actually is qmail-run, as can be read from the
README.Debian's in the qmail-run and qmail packages. And qmail-run
needs the qmail package, which provides the qmail programs and queue
structure, as well as the fastforward package, which provides support
for the /etc/aliases database. I can't see anything wrong with this, to
the contrary, the modularity of the packages provides more flexibility,
e.g.:
o users can install the qmail package without the qmail-run package to
configure qmail as MTA manually, next to another MTA package already
installed on the system
o users can install the qmail package without the qmail-run package if
they wish to use some programs from the qmail package, e.g.
qmail-popup and qmail-pop3d, and wish to have a different default
MTA installed, such as postfix
o users can disable the /etc/aliases support, and switch to a different
alias handling if they like; the package providing the /etc/aliases
database support can then be removed from the system
> 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
I fixed this in -2, users and groups are now handled in the postinst.
> * Uses useradd instead of adduser (policy 9.2.2)
As I read the policy, 9.2.2 mandates adduser for dynamically allocated
users and groups, but not globally allocated. Since the qmail uids and
gids are in the 60000-64999 range, useradd/groupadd should be just fine.
> * Why install the uids/gids in preinst?
I fixed this in -2, users and groups are now handled in the postinst.
> * User interaction without using debconf (policy 3.9.1) in both preinst and
> postrm (ok, it's just giving info, but still)
This hasn't changed.
> * Aborts in preinst if:
> - "Upgrading" from a pre 1.06 version (presumably unofficial)
Yes, by intention. I can't see how this is a reason for reject, other
new package don't care at all if they replace some unofficial or
non-free packages, possibly breaking a working installation. I think
aborting in that case is a good thing.
> - 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?)
The qmail-uids-gids package is a build-dependency of netqmail.
> * Recommends manual use of userdel and groupdel rather than deluser /
> delgroup in postrm
This hasn't changed.
> qmail
> * Installs /var/lib/qmail with alias, bin, boot, queue directories
Yes, shouldn't be a reason for reject.
> - Also:
> + users symlink to /etc/qmail/users/
> + control symlink to /etc/qmail/
> + doc symlink to /usr/share/doc/qmail/
Yes, shouldn't be a reason for reject.
> - bin/ contains mostly symlinks back to /usr/bin and /usr/sbin but
> one binary is present (config-fast)
Yes, in -2 the config-fast program is moved to /usr/lib/qmail/bin/.
> - boot/ contains what looks like scripts (should probably be in
> /usr/lib/qmail with a symlink if necessary)
Yes, in -2 the boot/ subdirectory is moved into /usr/lib/qmail/, and
symlinked back.
> - 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)
Yes, shouldn't be a reason for reject.
> * Aborts in postinst if system doesn't have FQDN
Yes, I can't see anything wrong with this.
> 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...
This hasn't changed.
> * C/R/Ps mail-transport-agent
> - Now, this does provide /usr/{sbin,lib}/sendmail
Yes, as said above, qmail-run is the package providing the MTA
functionality, shouldn't be a reason for reject.
> - 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
I changed that in version 2.0.1. qmail-run now recommends the
fastforward package, which in version -2 by default supports the
/etc/aliases database, and also includes the newaliases program.
> * Why is qmailctl in /usr/bin?
Because it might be of use for other accounts than the system
administrator.
> * preinst break on upgrades *AGAIN*
> * postinst errors if no FQDN
Yes, as above, shouldn't be a reason for reject.
> * 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
I'm sorry, I did not yet write them, that shouldn't be a reason for
reject.
> dot-forward only has
> * Lots of code duplication from netqmail in the supporting code (alloc
> routines etc). Apparently djb hasn't heard of libraries.
This shouldn't be a reason for reject.
> And finally qmail-tools:
> * Native tarball contains upstream tarball for queue_repair.py
Yes.
> * Package mainly to help with upgrading from non-free / unofficial packages,
> but the scripts just state that it isn't supported...
I prepared the hooks to implement upgrades from non-free and unofficial
qmail packages, but not yet the upgrade process itself. I'm ready to do
so once the packaging has stabilized and the packages are accepted.
Again, I can't see anything wrong with this, other new packages don't
provide this convenience at all.
> * So only use is queue_repair.py; why native?
>From what I read from debian-devel over the years, simple one-script
packages are not very popular, and usually it's advised to include the
script into another package providing similar functionality. There've
been a lot of scripts developed around qmail through the years, and I
expect that users will ask to have some packaged for Debian. The
qmail-tools package should then be the place for this.
> * /usr/sbin/queue_repair is a horribly generic name
Hm.
> 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.
We all know, I guess, that there's lots of different opinions on the
quality and usability of qmail. There're people thinking like you, and
other people, including me, that have a different opinion. I respect
your opinion, please respect ours too. You're free to not install/use
the packages. I've been contacted by several people since I announced
my intention to package qmail, speaking in favor of the inclusion into
Debian.
A public discussion already took place
http://thread.gmane.org/gmane.linux.debian.devel.wnpp/69292/
I think your advise to start a discussion to gather support for the
packages is backwards. Debian is about free software and users, the
qmail packages are free software, and users request the inclusion into
Debian. If you are interested in not having qmail in Debian, you are
free to start a public discussion to find supporters for your position,
I guess you'll get some objections too.
This is a good quote from the thread above
http://article.gmane.org/gmane.linux.debian.devel.bugs.general/345930
"Whether or not it's a good MTA, the fact is that it's a *popular* MTA.
That alone should be a good reason to package it."
> --
> bye Joerg
>
>
>
> ===
>
> If you don't understand why your files were rejected, or if the
> override file requires editing, reply to this email.
Regards, Gerrit.
Reply to: