Sam Varshavchik wrote:
> As I understand, rpm's default settings now reject fuzz in patch files, so
> you'll just have to do it, now.
"%define _default_patch_fuzz 2" (or even 3) can do miracles. :-p
> And since the likelyhood of configure changing in a new release is no
> different than any other source file getting changed
This is a wrong assertion to start from: configure tends to change a lot
since configure.ac gets changed at least once per version (to bump the
version) and upstream will regenerate configure with the then-current
configure.ac on their then-current distro. Sometimes, it's not even the
same person regenerating configure each time, so it can get regenerated on
completely different distros. Plus, as even small patches to configure.ac
can change a lot in configure (e.g. line numbers all over the place) and as
upstream WILL regenerate configure, not patch it directly, fuzz is a lot
more likely in configure than configure.ac.
> on average, believing that some work can be saved just by choosing to
> patch a different file, then the one that really needs to be patched, is
> somewhat naive.
It's believing it can't which is naive. All evidence points towards the fact
that patching configure.ac is indeed less work for changes.
> Because autoconf and automake are going to change a lot more than just
> what the patch was intended to patch. It's fairly likely that the upstream
> is using a different version of autoconf and automake, so this ends up
> producing a brand new configure and makefile. If I were to do that, then
> I would find it necessary to spend additional time testing the new
> configure script, running it an eyeballing all of its voluminous output,
> watching for something that falls out, as a result of the new configure
> script.
And you think upstream does that? On the autotools-using stuff I'm now
upstream for (no, it wasn't my decision to use autotools, and yes, moving
to CMake is a high-priority todo item), I just run "autoreconf -i -f" with
the latest autotools updates of the version of Fedora I'm currently running
and ignore all the warnings.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
