[ Please make your MUA understand Mail-Followup-To ]
On Thu, Jun 28, 2001 at 12:12:14PM +1000, John Newbigin wrote:
> You may distribute a precompiled package if
[ ... ]
> installing your package produces exactly the same files, in exactly
> the same locations, that a user would obtain
> by installing one of my packages listed above;
> My RPM produces exactly the same file and directory structure with the
> exception that I have removed the cat pages. If that is a problem then
> they could be added back in. The RPM spec was generated by the hier.c
> code and I have verified the installed package with instcheck.
> I have applied my own patch which removes the uid/gid problems and I
> have added a redhat 6.2 style rc script. The source rpm contains the
> original qmail-1.03.tar.gz and my 2 patch files.
A source RPM is not a precompiled package; so I don't see a problem with
this, especially since Bruce Guenter is also distributing one. Bruce may
have obtained permission from Dan, however, you'll have to ask him.
> your package behaves correctly, i.e., the same way as normal
> installations of my package on all other systems;
> and
> What exactly is meant by that? There is no standard installation
> procedure and there is no reference package so what constitutes correct
> behaviour?
It means tbat if you apply patches that modify the behaviour of qmail, you
can't redistribute the _binary_ package. In my interpretation, this excludes
modifications to the installation procedure.
[...]
> All installations must work the same way; any variation is a bug. If
> there's something about a system (compiler,
> libraries, kernel, hardware, whatever) that changes the behavior of
> my package, then that platform is not supported,
> and you are not permitted to distribute binaries for it.
> All installations must work the same way as what? My RPM is built for
> RedHat 6.2 only.
All installations must work the same way as an installation from source,
without modifications on a supported platform. So adding an rc script in
/etc/rc.d is not a problem, but installing a modified qmail-send that sends
obscene bounce-messages is not.
> I have built the RPM's for my own use but I would like to do what I see
> a a service to the community and make them available to help rid the
> world of sendmail. I hope that the barrier to doing this is not too
> great.
While I appreciate the sentiment, I think this specific community will not
benefit from additional (packaged) distributions. There is already a wide
variation of installation instructions and a fairly major modified
distribution, all of which are supported in this forum. I fear that adding
another one (that doesn't add any significant features to Bruce's version)
will only add to the support load here.
It is my opinion that the best way to install qmail, _especially_ for
inexperienced qmail users, is to build from source, using either Dan's
instructions or Life With Qmail. Mailservers in general and qmail especially
are not trivial software; they're network-accessible services that have
significant operational and security-implications. This means that making
new users read a lot of documentation is a _feature_, not a bug.
If you really want to do this, I think your safest choice is to only
distribute the source RPM, or obtain specific permission from Dan to
distribute the binary RPM.
Vince.
