On Tue, Sep 05, 2000 at 10:30:57AM -0400, Russell Nelson wrote:
> Adam McKenna writes:
> > Without even looking at them, I can tell you the following:
> >
> > 1) *if* the packages comply with dist.html, they will _never_ get into
> > potato.
> > 2) If they don't comply with dist.html, you will not be allowed to
> > distribute them.
> >
> > It's basically a lose/lose situation. If you want dist.html-compliant debs
> > for your own use or for unofficial use, that's fine. But they will never go
> > into debian, because they are in gross violation of debian's packaging
> > policy, and also there are already source packages for these programs in
> > debian.
>
> I don't understand why Debian doesn't have exceptions for packages
> which require cross-platform compatibility. Is the concept of a piece
> of software which uses the same pathnames no matter where you
> encounter it so strange? And all of the compatibility can be achieved
> through symlinks, so what's the big deal? Binaries can actually be
> stored in /usr/bin, control files can actually be stored in
> /etc/qmail, the queue can actually be in /var/spool. All that Dan
> insists on (and it's a reasonable insistance) is that anyone can sit
> down at a qmail installation and say "vi /var/qmail/control/locals".
>
That's not the big deal. The packages I did (qmail + fastforward +
dot-forward) just do exactly what You describe. The var-qmail tree as result
of these packages is ok.
The package qmail-run is no problem, it does not have to fullfill djb's
guidelines.
But: a sensible installation of qmail is based on ucspi-tcp and daemontools.
I do not want to have debian-packages of qmail, running qmail-smtpd out of
inetd, and I would prefer doing logging with multilog, not syslog.
As we know, there is no licence or dist.html covering these two projects.
There is one part in 'The Debian Free Software Guidelines' that will prevent
qmail from being in the main-section of debian, the non-free section is
possible:
http://www.debian.org/doc/debian-policy/ch2.html#s-pkgcopyright
Integrity of The Author's Source Code
The license may restrict source-code from being distributed in
modified form only if the license allows the distribution of `patch
files'' with the source code for the purpose of modifying the program
at build time. The license must explicitly permit distribution
of software built from modified source code. The license may require
derived works to carry a different name or version number
from the original software. (This is a compromise. The Debian group
encourages all authors to not restrict any files, source or
binary, from being modified.)
Gerrit.
--
[EMAIL PROTECTED]
innominate AG
networking people
tel: +49.30.308806-0 fax: -77 http://innominate.de
