Thank you for your advice and willingness to help with testing. There is a plan to create a side tag and test appropriate changes there.

Changed category to system-wide change.

Ondrej

On Thu, Feb 11, 2021 at 3:42 PM David Cantrell <dcantrell@redhat.com> wrote:
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@redhat.com>
Red Hat, Inc. | Boston, MA | EST5EDT
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure