Sam Varshavchik wrote:
> You're changing the topic.
No, you're the one changing the topic.
> On this point, we're not talking about what happens when autoconf changes.
> Here, the original statement was that patches to configure.ac are less
> likely to be kicked out than configure, if configure.ac changes.
The original statement was: (Adam Jackson wrote:)
| I suppose it depends whether you consider the initial act of package
| creation, or the continued maintenance of that packaging, to be more
| time consuming. All I know is that rediffing patches to configure.ac
| takes way less time than rediffing against configure, and that as a
| practice that hasn't (non-trivially) bitten me once in over three years,
| where configure patches have.
What he was talking about is that rediffing patches, i.e. making patches
apply to a new upstream version (that's what "rediffing" means for us Fedora
packagers), is more likely to break for configure.ac than for configure.
So your "if configure.ac changes" part was not in the original topic,
instead it was that patches to configure.ac are less likely to be kicked out
than configure when upgrading to a new upstream version.
> I pointed out that this is completely absurd, and you have no idea how
> autoconf works. You have no answer, so you must now start talking about
> what happens when autoconf itself changes.
Nonsense. This was always part of the original topic, you have just been
ignoring it. New upstream versions also use new autoconf versions.
> This is absurd. configure.ac changes due to natural evolution of the
> package far more often than autoconf itself changing.
>
> In fact, many actually loathe switching to a different version of
> autoconf, preferring to stay on the same version as long as possible.
[snip]
> Which happens far less often than routine changes to configure.ac, as the
> package natural evolves over time. autoconf changes happens maybe once
> every other year or so. Most configure script change far more often than
> once every other year.
I don't know what upstreams you worked with. For the projects I worked on
with Romain Liévin, he generally ran autoreconf with what was current on
Debian unstable or testing that day and me with what was current on Fedora
(stable updates) that day. The stuff would even ping-pong between the Debian
and Fedora versions. And even when it was the same person regenerating it,
it changed all the time. Fedora updates and Debian unstable/testing both get
autotools updates much more often than once every other year. Most
developers do not work on an enterprise distribution nor do they build their
own autotools. They use whatever is current on their fast-moving
distribution.
configure.ac itself only got minimal changes (the most frequent one was
bumping the version number).
> This is a bogus argument.
No, it isn't. See above. See also Ajax's statement I quoted again.
> It would be trivial to pick a typical package, and look at intervening
> releases, years apart, and observe the major differences in configure.ac,
> yet, perhaps only one, if none, update to autoconf itself occuring in all
> the intervening releases.
What's your "typical package"? Definitely not the ones I worked on.
> But, once I do that, you'll abandon this reasoning too, once you realize
> that it's a non-starter, and change the topic to something else. It'll
> probably be line number changes.
Nonsense. I'm not being intentionally dishonest, please stop those
unwarranted accusations!
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
