1 |
>>>>> On Wed, 10 Aug 2016, NP-Hardass wrote: |
2 |
|
3 |
> I was going through my packages to make sure that I was compliant with |
4 |
> this change, and found that I was not. The l10n eclass makes use of the |
5 |
> LINGUAS USE_EXPAND and isn't covered in the tracker bug. I attempted to |
6 |
> read through the old thread to see if someone mentioned that eclass, but |
7 |
> I must have missed it if someone mentioned it. Are we EOL'ing that |
8 |
> eclass, or keeping it (update or revbump)? |
9 |
|
10 |
> Looks to me like we can't edit that eclass in place, so if we are to |
11 |
> keep it, we should probably revbump it, update the -r1 to L10N, and add |
12 |
> a deprecation warning to the old eclass to help maintainers migrate over. |
13 |
|
14 |
> Any opinions? I'd be happy work on the revbump for the eclass if we |
15 |
> decide to go that route. CC'ing yngwin since it is his eclass. |
16 |
|
17 |
I briefly looked at packages inheriting l10n.eclass and it seems that |
18 |
a large fraction (or even most?) of them inherit it only for the |
19 |
following snippet of global scope code but don't use any of its |
20 |
functions: |
21 |
|
22 |
# Add linguas useflags |
23 |
for u in ${PLOCALES}; do |
24 |
IUSE+=" linguas_${u}" |
25 |
done |
26 |
|
27 |
Note that this won't be needed any more once we remove LINGUAS from |
28 |
USE_EXPAND. |
29 |
|
30 |
Apart from that, the general rule for conversion should be that |
31 |
packages whose upstream build system uses LINGUAS should stay with |
32 |
LINGUAS (which in the ideal case should be transparently passed to the |
33 |
build system). On the other hand, any downstream conditionals, e.g. in |
34 |
*DEPEND or SRC_URI, should be migrated to L10N. |
35 |
|
36 |
Ulrich |