1 |
Ühel kenal päeval, P, 11.06.2017 kell 13:08, kirjutas William Hubbs: |
2 |
> On Sun, Jun 11, 2017 at 07:14:52PM +0300, Mart Raudsepp wrote: |
3 |
> > Ühel kenal päeval, P, 11.06.2017 kell 11:12, kirjutas William |
4 |
> > Hubbs: |
5 |
> > > On Sun, Jun 11, 2017 at 05:35:53PM +0200, Kristian Fiskerstrand |
6 |
> > > wrote: |
7 |
> > > > On 06/11/2017 05:24 PM, David Seifert wrote: |
8 |
> > > > > > We can always patch the eclass at that point if that is |
9 |
> > > > > > still a |
10 |
> > > > > > big |
11 |
> > > > > > concern, but I fundamentally agree with William on this, |
12 |
> > > > > > starting |
13 |
> > > > > > point |
14 |
> > > > > > should be fixing it upstream, so can start with a tracking |
15 |
> > > > > > bug |
16 |
> > > > > > on |
17 |
> > > > > > affected packages. |
18 |
> > > > > > |
19 |
> > > > > |
20 |
> > > > > Here's a deal: you can start filing + fixing them. |
21 |
> > > > > |
22 |
> > > > |
23 |
> > > > The [tracker] is already started, it was determined to add QA |
24 |
> > > > warning |
25 |
> > > > with info on filing upstream bugs in [bug 426262] and the |
26 |
> > > > proper |
27 |
> > > > solution is again iterated in [bug 546614], so its not like |
28 |
> > > > this is |
29 |
> > > > a |
30 |
> > > > new approach that is being suggested, but sure, we should all |
31 |
> > > > file |
32 |
> > > > bugs |
33 |
> > > > when we encounter them. |
34 |
> > > > |
35 |
> > > > References: |
36 |
> > > > [tracker] https://bugs.gentoo.org/show_bug.cgi?id=530632 |
37 |
> > > > |
38 |
> > > > [bug 426262] |
39 |
> > > > https://bugs.gentoo.org/show_bug.cgi?id=426262 |
40 |
> > > > |
41 |
> > > > [bug 546614] |
42 |
> > > > https://bugs.gentoo.org/show_bug.cgi?id=546614 |
43 |
> > > |
44 |
> > > It seems that the proper fix to this, even for a package that |
45 |
> > > won't |
46 |
> > > do |
47 |
> > > the fix upstream is to use WANT_AUTOCONF in the ebuild to force |
48 |
> > > the |
49 |
> > > version of autoconf you need. |
50 |
> > |
51 |
> > No. It appears you don't know how WANT_AUTOCONF works. |
52 |
> |
53 |
> |
54 |
> From the eclass: |
55 |
> |
56 |
> # @ECLASS-VARIABLE: WANT_AUTOCONF |
57 |
> # @DESCRIPTION: |
58 |
> # The major version of autoconf your package needs |
59 |
> |
60 |
> That leads me to believe that you can set WANT_AUTOCONF="someversion" |
61 |
> in your ebuild and your package will use that version of autoconf. |
62 |
> |
63 |
> If that's wrong, it needs to be fixed and that's a different bug |
64 |
> entirely, but it doesn't change my position on adding this particular |
65 |
> change to autotools.eclass. |
66 |
|
67 |
It is the major version, as documented. Yes, it could specify what |
68 |
these valid versions currently are, as they really are: |
69 |
|
70 |
none |
71 |
2.1 |
72 |
2.5 |
73 |
latest |
74 |
|
75 |
Currently latest equals 2.5 and is the default. |
76 |
|
77 |
In practice, none means not to add an autoconf atom to DEPEND (even |
78 |
with the default AUTOTOOLS_AUTO_DEPEND=yes) - if ebuild/eclass |
79 |
inheriting autotools.eclass handles its own exact autoconf depend atom |
80 |
(eautoconf will get called in eautoreconf regardless). Only main tree |
81 |
consumer of this appears to be gtk-sharp-module.eclass that adds its |
82 |
own autoconf/automake atoms when needed, because eautoreconf is |
83 |
conditional by variables used by that eclass and it needed autoconf |
84 |
2.61 or newer, not just 2.59. |
85 |
|
86 |
2.1 means autoconf:2.1 |
87 |
|
88 |
2.5 and latest currently means >=autoconf-2.59 |
89 |
|
90 |
Patches welcome to documentation, I suppose. |
91 |
|
92 |
|
93 |
It is usually a bad sign if you need to change it away from latest for |
94 |
some reason in the ebuild and ideally they'd all be the default |
95 |
(latest). |
96 |
|
97 |
There was no configure.ac before autoconf-2.50, only configure.in, and |
98 |
thus a warning doesn't make sense. The real warning here is the need |
99 |
for WANT_AUTOCONF=2.1 |
100 |
|
101 |
|
102 |
HTH, |
103 |
Mart |