Status of libtool 2.2.X?

[Kevin Kofler]

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