Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
I know we're still waiting for Gerrit to be available before proceding much
further with this, but I wanted to lay out my own point-by-point analysis of
the reasons given for rejection to help us start to work out what the
current consensus is regarding which issues should or shouldn't be blockers.
On Thu, Jan 01, 2009 at 05:46:08PM +0100, Joerg Jaspert wrote:
> Criteria that speak against inclusion:
> - no real upstream
Neither necessary nor sufficient to block the package over the wishes of the
uploader.
> - 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)
Can you expand here on the consequences of ignoring RFC1894? I'm aware that
qmail delivery failure mails look different (and, I might argue,
gratuitously so) than those of other mail systems, but does this cause
interoperability problems for other Internet users?
The backscatter spam issue is, IMHO, sufficient reason to block this package
from being accepted into the archive. Debian should not be in the position
of facilitating the deployment of servers that are "bad citizens" on the
Internet.
The other issues are reasons not to use qmail, but I don't think they're
grounds to keep it out of the archive.
> - we do have many other, way more modern and better supported,
> MTAs available.
Neither necessary nor sufficient to block the package over the wishes of the
uploader.
> - 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.
Policy is clear on this point, and I think it's appropriate for the ftp team
to treat this as a blocker for archive acceptance. This is a serious policy
violation for a couple of different, *practical*, reasons:
- If the package which contains the newaliases command is not the package
which Provides: m-t-a, then the Conflicts/Replaces: m-t-a of all other MTA
packages will fail to match here and will result in dpkg file conflict
errors. It is not reasonable to ask all other MTA packages to Conflict:
m-t-a, fastforward in response to this. (Cf. the discussions on
debian-devel in early/mid 2008 regarding creation of a "default-m-t-a"
package.)
- If the package which Provides: m-t-a neither contains nor depends on a
package containing /usr/bin/newaliases, then the interface specified by
Policy is not guaranteed to be available, so packages which Depend:
mail-transport-agent may fail despite having their dependencies satisfied.
Serious policy violations are, IMHO, sufficient reason to block a package
from reaching the archive. Doubly so if the maintainer appears to be
unwilling to resolve them.
> - Still seems to violate the FHS. /var/lib/qmail/queue belongs into
> /var/spool, as far as we can tell.
Looking at the FHS, I see no indication that the mail queue is required to
be located under /var/spool, and the distinction between "spool data" and
"variable state information" is a fuzzy and debatable one. So I don't think
this is a policy violation, and therefore it shouldn't block inclusion in
the archive.
I would still certainly *encourage* the maintainer to evaluate whether
/var/spool would be a better location for this data. One of the values of
the FHS is in providing a clear heirarchical structure that can be used as
the basis for a generic backup policy, or for provisioning disks/filesystems
with different performance characteristics. Adhering to the FHS has
practical benefits.
> - 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.
It is a violation of Policy's requirements regarding the FHS.
9.1.1. File system Structure
----------------------------
The location of all installed files and directories must comply with
the File system Hierarchy Standard (FHS), version 2.3, with the
exceptions noted below, and except where doing so would violate other
terms of Debian Policy.
The files must be installed in /usr, not just symlinked from /usr.
This is a much more clear-cut violation of the FHS than the spool/lib
question, and I think it's reasonable to block a package from main that
misuses /usr vs. /var. Practical consequences here: having to store more
files on a filesystem that must be mounted read-write during normal
operation, marginally increasing the risk of fs corruption and possibly
consuming scarce writable media in some system configurations (embedded
systems?); requiring more complex MAC rules on SELinux et al.
> - 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.
As noted elsewhere in the thread, this is entirely compliant with policy
and should absolutely not be grounds for exclusion from the archive.
> - 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)
Neither necessary nor sufficient to block the package over the wishes of the
uploader.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Reply to: