Not yet released, so using 9999 for now.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=764ce7a97cdbe7f151e34b9008eee9e46bc4f56d commit 764ce7a97cdbe7f151e34b9008eee9e46bc4f56d Author: Sam James <sam@gentoo.org> AuthorDate: 2023-12-23 16:37:00 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-12-23 16:56:48 +0000 sys-devel/autoconf: add 2.72 Keywording immediately given I've been running 9999 for ages and we'd backported some of the bigger (but not all) changes anyway. It has a bunch of the modern C stuff we really want out there. Bug: https://bugs.gentoo.org/893434 Signed-off-by: Sam James <sam@gentoo.org> sys-devel/autoconf/Manifest | 2 + sys-devel/autoconf/autoconf-2.72.ebuild | 92 +++++++++++++++++++++++++++++++++ sys-devel/autoconf/autoconf-9999.ebuild | 12 +++-- 3 files changed, 103 insertions(+), 3 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=00a85ac2928bf83ec841a08904b2e80008276ce2 commit 00a85ac2928bf83ec841a08904b2e80008276ce2 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-12-27 19:12:04 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-12-27 20:57:06 +0000 autotools.eclass: rework WANT_AUTOCONF handling For automake, we enumerate each of the automake slots in _WANT_AUTOMAKE and use this to handle setting WANT_AUTOMAKE accordingly if the ebuild (or user, I suppose) haven't set WANT_AUTOMAKE themselves. This means that we can easily rollover to the latest installed on a system (and we also pull it in via _WANT_AUTOMAKE which is used for dependencies) because WANT_AUTOMAKE is based on the slots in _WANT_AUTOMAKE intersected with whatever is installed on the system. For autoconf, we weren't doing any of that, and were just hardcoding whatever the latest slot is! That's error prone on bumps but it also wasn't really possible to get right as-is without marking a new slot stable because of the entanglement between the dependencies, WANT_AUTOCONF, and no intersection being done (WANT_AUTOCONF wasn't dynamic at all). We now implement a similar scheme for autoconf as we already had for automake. This fixes the case where WANT_AUTOCONF="latest" in an ebuild (the default), autoconf:2.71 isn't installed, but autoconf:2.72 is. This sometimes worked before if the latest dep was slotted rather than unslotted like it is now (see below for why that's not easy to just fix) because the new slot would never get pulled in and hence the older slot which aligned with WANT_AUTOCONF's hardcoded value would be available. (I still think we should consider slotmoving older autoconfs but that's something to discuss and possibly do another time. See TODO.) Bug: https://bugs.gentoo.org/827852 Bug: https://bugs.gentoo.org/893434 Closes: https://bugs.gentoo.org/920822 Signed-off-by: Sam James <sam@gentoo.org> eclass/autotools.eclass | 73 +++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 67 insertions(+), 6 deletions(-)
Note that some failures/bugs aren't new but just show up because of the portage change wrt not ignoring command not found in configure.
