1 |
On Fri, Jul 20, 2012 at 1:09 PM, Ciaran McCreesh |
2 |
<ciaran.mccreesh@××××××××××.com> wrote: |
3 |
> On Fri, 20 Jul 2012 12:39:21 -0400 |
4 |
> Mike Gilbert <floppym@g.o> wrote: |
5 |
>> On Fri, Jul 20, 2012 at 2:54 AM, Ciaran McCreesh |
6 |
>> <ciaran.mccreesh@××××××××××.com> wrote: |
7 |
>> > On Thu, 19 Jul 2012 18:34:41 -0400 |
8 |
>> > Mike Gilbert <floppym@g.o> wrote: |
9 |
>> >> On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico <zmedico@g.o> |
10 |
>> >> wrote: |
11 |
>> >> > On 07/19/2012 06:14 AM, Ralph Sennhauser wrote: |
12 |
>> >> >> Could be that Portage re-exports a sanitized |
13 |
>> >> >> LINGUAS tough, but I doubt it. |
14 |
>> >> > |
15 |
>> >> > Portage does sanitize it if there are any linguas_* flags in |
16 |
>> >> > IUSE, otherwise it lets the variable pass through without |
17 |
>> >> > sanitizing it. |
18 |
>> >> |
19 |
>> >> That's good; we definitely don't want to "sanitize" it if there |
20 |
>> >> are no linuguas_* flags in IUSE. This would break LINUGUAS support |
21 |
>> >> for many autotools/gettext based packages, where the autotools |
22 |
>> >> code parses LINGUAS directly and the ebuild does nothing with it. |
23 |
>> > |
24 |
>> > If there aren't any linguas_* flags in IUSE, LINGUAS should be |
25 |
>> > empty, and will be in future EAPIs. Without that, USE dependencies |
26 |
>> > on USE_EXPAND variables don't work. |
27 |
>> |
28 |
>> How do you figure that? |
29 |
> |
30 |
> If you dep upon foo[linguas_en(+)] and linguas_en isn't in IUSE, what |
31 |
> happens? |
32 |
> |
33 |
|
34 |
Firstly, if there are no linugas_ flags in IUSE, I can't see any point |
35 |
in such a dependency. |
36 |
|
37 |
Given the current behavior, I believe the dependency would always |
38 |
satisfied due to the (+). That seems fine to me. |
39 |
|
40 |
>> The current portage behavior works well enough; if linugas_* is in |
41 |
>> IUSE, LINGUAS is treated as a USE_EXPAND, and use-deps should work |
42 |
>> fine. |
43 |
>> |
44 |
>> Otherwise, it is treated just like a normal environment variable, and |
45 |
>> portage doesn't touch it. |
46 |
> |
47 |
> It's not a normal environment variable, and it never has been. |
48 |
> |
49 |
|
50 |
It was a normal variable before someone added it to USE_EXPAND. From |
51 |
cvs, it looks like that happened in 2005 or so. |
52 |
|
53 |
>> For most gettext packages, there is absolutely no reason that the |
54 |
>> ebuild maintainer should have to keep track of every translation |
55 |
>> available in a given package across version bumps. If you change this |
56 |
>> behavior in a future EAPI, you will break this. |
57 |
> |
58 |
> Don't use a USE_EXPAND variable if you don't want USE_EXPAND behaviour. |
59 |
> |
60 |
|
61 |
I beleive LINGUAS originates from the autoconf macros (po.m4) provided |
62 |
by the gettext package. I believe we added it to USE_EXPAND some time |
63 |
after it was implemented in gettext. This "just works" given the |
64 |
current portage behavior. |
65 |
|
66 |
Perhaps we need to provide a cleaner way for ebuilds to specify if a |
67 |
given variable should be treated as a USE_EXPAND or not. |