Braden McDaniel <braden <at> endoframe.com> writes:
>
> On Mon, 2008-10-13 at 09:16 -0400, Adam Jackson wrote:
> > No thanks. Patching Makefile.am at least stands a chance of applying
> > correctly across multiple releases of the package.
>
> Patching Makefile.in stands a reasonable chance of that, too. Exactly
No it doesn't.
> what the odds are depends greatly on the nature of the change; and it is
> certainly the case that for a class of changes, the patch to Makefile.am
> is more likely to apply cleanly. Your implication that a patch to
> Makefile.in stands no chance of applying cleanly to future releases is
> simply hyperbole.
No it isn't. Adam Jackson (ajax) is an experienced packager, he knows what he's
talking about!
> > Worse, patching the
> > generated files stands a good chance of missing an instance of whatever
> > you were patching for when the next release comes out.
>
> I think the claim of such a "good chance" is, once again, hyperbole.
> Sure, there's *some* chance. And there's *some* chance of that
> regardless of what you file patch. Again, just what sort of increase to
> the likelihood of failure we're talking about depends greatly on the
> nature of the change.
Again, I'm sure Ajax is talking from experience there, not inventing things.
How many packages have you maintained to come to your conclusion?
> where you're coming from. But I have a problem with the practice of
> regenerating these files when the broad application of this practice
> winds up presenting a serious impediment to upgrading one of these build
> tools in Fedora. That didn't have to happen.
The real problem is that libtool is breaking compatibility, not that packages
are running libtool. We have exactly the same problems with e.g. GCC breaking
source compatibility (and I also blame GCC for doing that).
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
