Ühel kenal päeval, P, 11.06.2017 kell 13:08, kirjutas William Hubbs: > On Sun, Jun 11, 2017 at 07:14:52PM +0300, Mart Raudsepp wrote: > > Ühel kenal päeval, P, 11.06.2017 kell 11:12, kirjutas William > > Hubbs: > > > On Sun, Jun 11, 2017 at 05:35:53PM +0200, Kristian Fiskerstrand > > > wrote: > > > > On 06/11/2017 05:24 PM, David Seifert wrote: > > > > > > We can always patch the eclass at that point if that is > > > > > > still a > > > > > > big > > > > > > concern, but I fundamentally agree with William on this, > > > > > > starting > > > > > > point > > > > > > should be fixing it upstream, so can start with a tracking > > > > > > bug > > > > > > on > > > > > > affected packages. > > > > > > > > > > > > > > > > Here's a deal: you can start filing + fixing them. > > > > > > > > > > > > > The [tracker] is already started, it was determined to add QA > > > > warning > > > > with info on filing upstream bugs in [bug 426262] and the > > > > proper > > > > solution is again iterated in [bug 546614], so its not like > > > > this is > > > > a > > > > new approach that is being suggested, but sure, we should all > > > > file > > > > bugs > > > > when we encounter them. > > > > > > > > References: > > > > [tracker] https://bugs.gentoo.org/show_bug.cgi?id=530632 > > > > > > > > [bug 426262] > > > > https://bugs.gentoo.org/show_bug.cgi?id=426262 > > > > > > > > [bug 546614] > > > > https://bugs.gentoo.org/show_bug.cgi?id=546614 > > > > > > It seems that the proper fix to this, even for a package that > > > won't > > > do > > > the fix upstream is to use WANT_AUTOCONF in the ebuild to force > > > the > > > version of autoconf you need. > > > > No. It appears you don't know how WANT_AUTOCONF works. > > > From the eclass: > > # @ECLASS-VARIABLE: WANT_AUTOCONF > # @DESCRIPTION: > # The major version of autoconf your package needs > > That leads me to believe that you can set WANT_AUTOCONF="someversion" > in your ebuild and your package will use that version of autoconf. > > If that's wrong, it needs to be fixed and that's a different bug > entirely, but it doesn't change my position on adding this particular > change to autotools.eclass.
It is the major version, as documented. Yes, it could specify what these valid versions currently are, as they really are: none 2.1 2.5 latest Currently latest equals 2.5 and is the default. In practice, none means not to add an autoconf atom to DEPEND (even with the default AUTOTOOLS_AUTO_DEPEND=yes) - if ebuild/eclass inheriting autotools.eclass handles its own exact autoconf depend atom (eautoconf will get called in eautoreconf regardless). Only main tree consumer of this appears to be gtk-sharp-module.eclass that adds its own autoconf/automake atoms when needed, because eautoreconf is conditional by variables used by that eclass and it needed autoconf 2.61 or newer, not just 2.59. 2.1 means autoconf:2.1 2.5 and latest currently means >=autoconf-2.59 Patches welcome to documentation, I suppose. It is usually a bad sign if you need to change it away from latest for some reason in the ebuild and ideally they'd all be the default (latest). There was no configure.ac before autoconf-2.50, only configure.in, and thus a warning doesn't make sense. The real warning here is the need for WANT_AUTOCONF=2.1 HTH, Mart
