On Wed, Feb 10, 2021 at 12:30:20PM -0700, Jeff Law wrote:
On 2/10/21 11:00 AM, Miro Hrončok wrote:
On 10. 02. 21 18:47, Ben Cotton wrote:
== Upgrade/compatibility impact ==
Problems during build can appear in multiple packages what can lead to
build failure, as multiple packages require autoconf-2.69 as their
upstream dependency. These problems have to be resolved before adding
autoconf-2.71 into Fedora. It seems aprox. 20% of dependent packages
are having problems during build, which could be caused by a problem
with same pattern.
In absolute numbers, what is 20%? I see ~200 failures at
https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/monitor/
(obviously not all of them are necessarily caused by autoconf).
Should this be a system-wide change instead?
Given how many packages use autoconf, I think so.
+1
autoconf changes are a big build impact and [most?] maintainers like
to avoid surprises here.
I've already volunteered my tester to help shake out this change. It's
actually a really good fit because of the autoconf/LTO interactions we
had to sort out for F33/LTO. The plan is to spin it up next week.
In simplest terms autoconf generated code to test for the existence of
certain capabilities can be optimized away completely by LTO. This
results in autoconf incorrectly claiming certain capabilities exist.
This can cause packages to FTBFS or to even mis-behave at runtime.
Thus it was critical to find these cases and deal with them as part of
the LTO effort. So my tester has the ability to capture generated
config.h files across its control and test builds and will report a
failure if the generated config.h files differ (with an ability to
exclude those where timestamps and such end up in the generated config.h
files).
In the test I'm going to run the only difference between the control and
test build will be the version of autoconf. So the failures should give
us a highly accurate picture of how autoconf-2.70 will impact the
distribution as a whole.
This is a good idea. But really, I would like to see packages that
run autoconf during build to be checked. I do not think it is
sufficient to just check a subset of packages or even one particular
use case. I think to do this with minimal impact, we kind of need to
make sure everything using autoconf has incorporated the necessary
changes for autoconf-2.71. In many cases, things may be ready to go.
But I don't think we can assume that.
The approach mhroncok@ and others have used for major Python changes I
think could be applied here. As an autoconf user [under duress, but
still, I have to rely on it], I would like the opportunity to have an
autoconf-2.71 side tag to verify my packages build there before we
update rawhide with 2.71. We could automate builds to test things out
and file bugs for package maintainers for failures. I know this is a
lot of work, but I think the proactive approach is better than
throwing it in to rawhide and fixing the fallout.
I am volunteering to help perform these test builds and file bugs
and/or PRs for packages since what I am suggesting is a lot of work.
Thanks,
--
David Cantrell <dcantrell@xxxxxxxxxx>
Red Hat, Inc. | Boston, MA | EST5EDT
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
