1 |
On Fri, 20 Jul 2012 13:29:24 -0400 |
2 |
Mike Gilbert <floppym@g.o> wrote: |
3 |
> > If you dep upon foo[linguas_en(+)] and linguas_en isn't in IUSE, |
4 |
> > what happens? |
5 |
> > |
6 |
> |
7 |
> Firstly, if there are no linugas_ flags in IUSE, I can't see any point |
8 |
> in such a dependency. |
9 |
|
10 |
If linguas_ is in IUSE for some versions and not others. You know, as |
11 |
(+) dependencies always expect. |
12 |
|
13 |
> > It's not a normal environment variable, and it never has been. |
14 |
> |
15 |
> It was a normal variable before someone added it to USE_EXPAND. From |
16 |
> cvs, it looks like that happened in 2005 or so. |
17 |
|
18 |
...which is plenty long enough to have dealt with the consequences. |
19 |
|
20 |
> >> For most gettext packages, there is absolutely no reason that the |
21 |
> >> ebuild maintainer should have to keep track of every translation |
22 |
> >> available in a given package across version bumps. If you change |
23 |
> >> this behavior in a future EAPI, you will break this. |
24 |
> > |
25 |
> > Don't use a USE_EXPAND variable if you don't want USE_EXPAND |
26 |
> > behaviour. |
27 |
> |
28 |
> I beleive LINGUAS originates from the autoconf macros (po.m4) provided |
29 |
> by the gettext package. I believe we added it to USE_EXPAND some time |
30 |
> after it was implemented in gettext. This "just works" given the |
31 |
> current portage behavior. |
32 |
|
33 |
The problem with "just works" is that it "just works unless you look |
34 |
closely or unless you try to do something slightly non-trivial". We're |
35 |
not dealing with a small system here, so we need to move beyond "just |
36 |
works (sort of)" to "correct". We can't provide people with the |
37 |
features they're asking for without that. |
38 |
|
39 |
> Perhaps we need to provide a cleaner way for ebuilds to specify if a |
40 |
> given variable should be treated as a USE_EXPAND or not. |
41 |
|
42 |
USE_EXPAND isn't a per ebuild setting. |
43 |
|
44 |
-- |
45 |
Ciaran McCreesh |