>> (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? I think we did, yes. > Can you point us to the current source packages so that we can have a look > at them? merkel:~joerg/qmail >> 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? If I would know a solution thats ok for both sides I wouldn't ask someone else to jump in. Yet, I don't. What I see is that we do not want qmail. We do think Debian is best off without. Obviously Gerrit thinks differently. Unlike, for example, mplayer, this is not to solve by modifying the package itself (in mplayers case leaving out all the problematic bits of the source), as it's not about a not-too-important part of the source, but about the whole application. >> 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. He got an X-Debbugs-CC on the bug and also a reject mail pointing to it, so he definitely knows (when he reads his mail) that this is now with the TC. Noone said this has to be an immediate decision. I do expect the TC to seek his input at some stage of this. Considering that none of these packages will ever end up in Lenny, no matter what the decision is, waiting a bit more will sure not hurt. >> Criteria that speak against inclusion: >> - no real upstream > Why "no real"? Did Gerrit commit to something? DJB isn't doing it. Some others seem to maintain some set of patches. >> - 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. A goal of a distribution is to provide the best possible combination of software and partly also do a selection for the users of what is good and whatnot (by packaging it, supporting it in the distribution, etc). >> - we do have many other, way more modern and better supported, >> MTAs available. > Not a valid objection, we have way more window managers. And having one WM in NEW that has the same other points like Qmail has now, it would get the same refusal from our side. (Yet, a WM usually has no problems like qmail that affect the whole net and not only a single machine. Qmails mail behaviour fires back on everyone, no matter if they use it or not). >> - 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. It is one, out of many, reasons. >> - 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. Dito. -- bye, Joerg <HE> Lalalala ... Ich bin die Sponsoren-Schlampe - Wer hat heute Lust?
Attachment:
pgpZaFYzhXklP.pgp
Description: PGP signature