Qmail
[Top] [All Lists]

Re: qmail Patch Repository

To: Qmail mailing list <qmail@list.cr.yp.to>
Subject: Re: qmail Patch Repository
From: "Japheth J.C. Cleaver" <cleaver@redwire.net>
Date: Wed, 28 Feb 2007 11:53:24 -0800
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
Delivered-to: sp-com-lists@consult.net
Delivered-to: gmail-qmail@securepoint.com
Delivered-to: sp.com.list@gmail.com
Delivered-to: mailing list qmail@list.cr.yp.to
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=redwire.net; b=AysCu3hl54VlqnkjD9SnQxpqeu4aEBwa17nAAH9q3QJ7NPfdfrzB+D1d5UVl88fZNRqy2aZQHAvSqf8w2jC+IQZ4viIHa0QZBgScLtLPl6Ell3VJzlxjTIfQTktd5JXintr3JKueFNTxCJC2HU2+xENKMlpIv7Y6hz1JaJ0oUWo= ;
Domainkey-status: good
In-reply-to: <20070228161140.GF24361@nachos.phaseit.com>
Mailing-list: contact qmail-help@list.cr.yp.to; run by ezmlm
Organization: Airband Communications, Inc.
References: <45E59056.50008@cmcflex.com> <20070228151607.GB24361@nachos.phaseit.com> <20070228155340.GA10453@discworld.dyndns.org> <20070228161140.GF24361@nachos.phaseit.com>
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.9) Gecko/20061207 Thunderbird/1.5.0.9 Mnenhy/0.7.4.666
Fabio Busatto wrote:
> On Wed, Feb 28, 2007 at 09:53:40AM -0600, Charles Cazabon wrote:
>> Note that scattering tons of preprocessor conditionals through djb's code is
>> going to make it *less* readable and significantly increase the chances of
>> introducing bugs, possibly including security holes.
> 
> This is why I say that the code should not be intrusive.
> In my idea, additional features are implemented in their own program 
> functions,
> sorrounded by #ifdef, and not more than the function calling should happen in
> the original djb code.
> I see the bug introduction as a real problem, and this is why I started the
> iloveqmail project: to avoid bugs introduced by collating various patches 
> together.
> Unfortunately the hooks in the original code will overlap, but there is no 
> way to
> avoid it.
> 
> Fabio

Combined mega-patchsets also make it more difficult when the patch
originators release updates to their original code, as you now have to
go in and determine which parts of which patches in the 10K file were
changed to accommodate things in the first place.

Sadly, the only solution I came up for my own internal RPM was to
explicitly "patch the patches" in the package. It keeps things nice and
modular in terms of deciding what I'm applying, at the expense of
doubling the number of patches I'm dealing with and making the whole
build process much uglier.


-jc

<Prev in Thread] Current Thread [Next in Thread>