Braden McDaniel <braden <at> endoframe.com> writes:
> The premise that the patch you apply as part of the specfile build is
> the same one you should be submitting upstream is faulty.
[snip]
> Won't happen if you're only patching configure and Makefile.in, as you
> should.
If your original change was on configure.ac and Makefile.am and you're only
shipping the patch for the generated configure and Makefile.in, you're
violating the GPL.
> 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.
I don't see why this should be handled any differently from a new GCC version,
where the GCC maintainer will help with actual GCC bugs and in with diagnosing
some non-obvious problems, and also do a mass rebuild and report the results,
but ultimately it's the maintainer of the affected package who is responsible
for getting it to build with the latest GCC.
Still, it should be up to the maintainer to decide on the tradeoff (i.e. on
what's more work: forward-porting the patch for the generated files or getting
the package to build with newer libtool/auto*/... versions), and the autotools
maintainers should expect their new versions to break things and so handle them
like new GCC versions.
> > (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.
It's not whining, it's a statement of fact.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
