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