Russell Nelson <[EMAIL PROTECTED]> writes:
> Try applying two patches to the same program.
While this may require some manual reconciliation between
conflicting packages, it's far better than needing a seperate full
distribution of components of qmail for every possible combination of
patches.
For example, if there are 10 different patches against qmail-smtpd,
then there are 1,024 different packages that would have to be
available to support the various combinations of patches. Worse, as
more patches come out, this number increases exponentially. If I come
out with yet another patch to qmail-smtpd, all of a sudden we're up to
2,048 packages. And who is responsible for generating the additional
1,024 packages, me or the first 10 developers? If the 10 different
packages are all maintained by different people, let's say A-J,
obviously A is responsible for making qmail-smtpd-A available, and B
for qmail-smtpd-B. But is A or B responsible for qmail-smtpd-AB? And
what if A thinks B is an idiot, and B thinks A is? Either a third
party will have to create qmail-smtpd-AB, or else an end user who
wants qmail-smtpd-AB will be responsible for putting it together,
probably by downloading all of the packages, producing patches with
diff, and applying to the original qmail sources.
Further, the base qmail source is well-tested. It's easy to see
exactly how much is changed by a patch, and if there are problems, to
investigate only those areas which a patch affects. With a full
package, to isolate problems to just the patch's changes will require
you to download the original and the modified version, and use diff to
compare the changes, essentially giving you a patch file.
Still further, patches which touch multiple parts of qmail (such as
the ETRN patch) would require basically a redistribution of all of
qmail, which would make the exponential patch growth problem even
worse.
And still further yet, it's not even clear that qmail's distribution
terms allow this, without getting explicity permission from the
author for each new package:
DJB> If you want to distribute modified versions of qmail
DJB> (including ports, no matter how minor the changes are) you'll
DJB> have to get my approval. This does not mean approval of your
DJB> distribution method, your intentions, your e-mail address,
DJB> your haircut, or any other irrelevant information. It means a
DJB> detailed review of the exact package that you want to
DJB> distribute.
(from http://cr.yp.to/qmail/dist.html) If explicit permission is
required for each new package, it would make the time required to
produce a patch higher, which would discourage people from producing
patches or packages.
I think that the way it works now is the best it can currently be.
A better option is to take all of the common qmail patches, and
produce a new qmail package with them applied or available as options.
This would mean that more obscure patches could be against this
package, reducing the chance of conflicts, and that the package with
modifications would be well-tested. This, I believe, is similar to
the situation with ezmlm-idx.
------ScottG.
