Till Maas <opensource <at> till.name> writes:
> I do not understand, why the huge changes are a big problem. The massive
> amount of changes is how autotools work. The "hidden change" can imho be
> better seen in the patch to the autotools input files, which still exists.
> Also in case upstream is not dead and is still providing new versions, the
> upstreamed patch should be in the next released version, so you do not have
> to regenerate the patch.
Maybe in an ideal world, but here in the real world, not all patches get
upstreamed immediately in the next release, and unless this is a large
organized project like GCC which enforces very precise autotools versions, the
next release will often have used different autotools versions (either because
a different developer (often using a different distribution) generated the
autotools files or because the maintainer upgraded his autotools, which happens
often if they're using e.g. Debian unstable (also if they use Fedora, but in
that case, you have at least some hope of hitting the same autotools versions
they used)) and so a patch containing lots of bogus changes (i.e. differences
completely unrelated to your actual modifications) will almost certainly fail
to apply.
> In case there is a demand to recreate the patch often, we could add a helper
> target (prepare-patch) to Makefile.common that does: [...]
And this is a really complex solution with lots of manual work for the
maintainer to do at each upstream release (your proposed Makefile.common
snippets only automate small parts of it, which are just basic diff and patch
invocations anyway), you didn't even list all of them (for example, the source
tarball has to be extracted to rediff a patch).
So I don't get at all how you can think that this compares in simplicitly with:
BuildRequires: autoconf automake libtool
[and in the %prep section]
autoreconf
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
