On 11/06/17 04:02 PM, Mart Raudsepp wrote: > Ü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 >
I'm not seeing the issue with what William's suggesting -- if the configure.in is non-trivial to just rename in the ebuild, then setting WANT_AUTOCONF=2.1 would seem to me to be the correct course of action. If there's a package that has a configure.in but also needs autoconf:2.5, well, that seems messed up and likely should be fixed in the ebuild (or upstream) too.
signature.asc
Description: OpenPGP digital signature