Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
On Thu, 01 Jan 2009, Joerg Jaspert wrote:
> (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.
It's the first time I hear that the ftpteam has used this requirement to
reject packages. Have you used it for other packages already?
Can you point us to the current source packages so that we can have a look
at them?
> 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.
What constitutes for you a solution that works for both sides?
To me, it seems that you're deferring the decision to the tech-ctte and
that the tech-ctte must decide which side is right. But I don't see any
place yet where there's room for a compromise in this situation… or do you
expect that a subset of the source packages that are concerned would be
more acceptable than others?
> Criteria for inclusion that qmail meets:
> - active maintainer (Gerrit Pape)
Gerrit is not available until end of january so it seems rather badly
timed to bring this request forward now giving no chance to Gerrit to
give his arguments.
> Criteria that speak against inclusion:
> - no real upstream
Why "no real"? Did Gerrit commit to something?
Note that "cron" has no real upstream either, yet we use and support the
package. As long Gerrit is ready to handle all the issues that pop up, I
don't see this reason as blocker.
> - 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)
All those are good reasons to not choose the software as a user but not to
not include them in Debian. We don't know how our users are going to use
it and there might be use cases where those shortcomings are not
problematic.
We might want to document those shortcomings and in particular those that
affect the network as a whole (backscatter) so that newcomers can avoid
causing problems simply due to ignorance.
> - we do have many other, way more modern and better supported,
> MTAs available.
Not a valid objection, we have way more window managers.
> - 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.
I'm don't know the rationale of this requirement in policy, adding aliases
automatically is not really in the spirit of the policy that preserves
configuration files.
Anyway, changing the recommends to depends might be a solution.
> - Still seems to violate the FHS. /var/lib/qmail/queue belongs into
> /var/spool, as far as we can tell.
One more symlink in the package could resolve this. And I have seen
numerous other packages that had similar problems but that have been
accepted nevertheless. I don't think that it's a sufficient reason to
reject the package. It's enougr to open a bug report against the package
but not much more.
> - 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.
Same thing than above, it's not nice but it's an effective way to comply
with the FHS when upstream doesn't comply.
> - 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.
Not sure about this one, some investigation needed.
> - 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)
AFAIK we don't use this criteria to accept packages but only to remove them once
we have no active maintainer any more.
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
Reply to: