Re: Suggested packaging guideline: avoid running autoreconf

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

 



On Sat, 2008-10-11 at 18:32 +0000, Kevin Kofler wrote:
> Braden McDaniel <braden <at> endoframe.com> writes:
> > Rather than patching configure.[ac,in] and Makefile.am, a more resilient
> > approach is to patch the configure script and Makefile.in files.
> 
> Patching only the generated files is a hack which cannot be submitted upstream, 
> so usually you end up with a patch which touches both source files and 
> generated files, and that's a very fragile approach as:

The premise that the patch you apply as part of the specfile build is
the same one you should be submitting upstream is faulty.

> * often you have to run "touch" on generated files which are not affected by 
> the source change at all, because otherwise the autotools will try to be 
> smarter than you and regenerate everything because not all generated files are 
> up to date, and fail if the required autotools for regenerating everything are 
> not there, and

Won't happen if you're only patching configure and Makefile.in, as you
should.

> * such patches generally have to be copied from the sources to the generated 
> files by hand, because (as I explained in the other thread) regenerating them 
> generally results in huge patches due to subtle autotools version differences, 
> which then fail to apply to new upstream versions.

There are only two possible reasons for such a failure:

     1. Upstream has deliberately changed the same portion(s) of the
        file(s) your patch touches.  In this case, your patch is going
        to break no matter what.
     2. Upstream has built its package with a different version of the
        autotools than were used in the previous release.  In all but
        exceptional cases, "different" means "newer".  Yea, they care!
        Now why didn't they include the patch you sent them?

There can be all sorts of reasons for that.  But packagers faced with an
uncooperative upstream need to learn to live with the reality that their
package will be harder to maintain.  It should not be considered
acceptable behavior for packagers to punt and create work for the poor
guy who drew the short straw for the libtool (or whatever, as the case
may be) upgrade.

> (This is exactly why generated files in source tarballs are a major PITA and 
> the autotools are broken by design.)

Yes, this sort of whining is *really* productive.

-- 
Braden McDaniel                           e-mail: <braden@xxxxxxxxxxxxx>
<http://endoframe.com>                    Jabber: <braden@xxxxxxxxxx>


-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux