[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: an update to automake-1.11?



On 07/06/2009 08:09 PM, Braden McDaniel wrote:
> On Mon, 2009-07-06 at 16:36 -0700, Toshio Kuratomi wrote:
>> On 07/06/2009 03:57 PM, Braden McDaniel wrote:
>>> On 7/6/09 6:10 PM, Toshio Kuratomi wrote:
>>>
>>> [snip]
>>>
>>>> Introducing side-effects is something to watch out for but
>>>> patching configure instead of the true source is a short term fix, not a
>>>> long term solution.
>>>
>>> *Any* patch should be viewed as a short-term fix.  A patch that needs to
>>> persist indefinitely suggests broken maintainership somewhere along the
>>> line--either upstream, of the Fedora package in question, or elsewhere
>>> in Fedora's infrastructure.
>>>
>> <nod> But one of those patches is upstreamable and the other is not.
>> The upstreamable patch is a step on the road to the long term fix.  The
>> non-upstreamable one is a dead-end.
> 
> Creating a patch to configure/Makefile.in in no way precludes a package
> maintainer from sending an analogous patch to configure.ac/Makefile.am
> upstream.  So, yes, it's a "dead end" that:
> 
>      1. reduces the size of the changeset between the upstream package
>         and the one Fedora actually builds and
>      2. improves the resiliency of the package build to changes to
>         Fedora's autotools chain.
> 
Perhaps but it doesn't decrease the work that the maintainer has to do.
 The package maintainer needs to patch configure.ac so they have
something upstreamable.  Then they need to test that their changes make
the changes they think and don't break things via unintended
side-effects.  If they notice discrepancies, they have to find out what
is going on (whether it's a version difference in automake or a bug
introduced by their patch) and fix it.  Then they can submit that
upstream.  At that point, the reasons for creating a separate, even just
a few lines different code that directly changes configure is extraneous
work.

Do all maintainers do this kind of work when they make a patch for
configure.ac?  Perhaps not but they are doing their duties better if
they do.  Do all maintainers make upstreamable patches when they
directly fix a configure script?  I think the answer is the same.

-Toshio

Attachment: signature.asc
Description: OpenPGP digital signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]