Dnia 1 czerwca 2016 11:18:30 CEST, Mart Raudsepp <l...@gentoo.org> napisał(a):
>Ühel kenal päeval, T, 31.05.2016 kell 14:49, kirjutas Michał Górny:
>> Since the previous thread doesn't seem to have brought any good
>> solution to the problem other than stopping to (ab)use LINGUAS
>> as USE_EXPAND, I would like to start a RFC on a draft solution that
>> I'd like afterwards to propose to the Council.
>> 
>> 
>> Rationale
>> ---------
>> 
>> The direct reason for this is that LINGUAS is treated as non-standard
>> special variable by multiple build systems. This includes the
>> following
>> problems:
>> 
>> 1. no localizations are installed if it is set to an empty value
>> (which
>> happens in EAPI 5 when the ebuild does not use the flags),
>
>Why not just add a USE_EXPAND_DONTTOUCH variable to profiles, like
>there is already a USE_EXPAND_HIDDEN, which tells the PM to not play
>with the envvar, and just use it for USE expansion when the ebuild does
>use it?
>Point being, it leaves it unset, when it's unset, and it leaves it set
>to empty value or a value when it is so.
>
>Obviously with a better name than USE_EXPAND_DONTTOUCH, but you get the
>idea.

Excuse me but are you really serious? We are in this swamp because someone 
tried to be too smart. And what solution do you propose? Let's add another 
layer of complexity and smartness, for a single variable. Obviously nothing can 
go wrong with this.

>
>I suppose this doesn't solve the case of PM not knowing about what is
>inside a binary package, but if said variable also affected the
>metadata of the result, this should be possible to handled with some PM
>work, while not duplicating places to set languages to be
>compiled/installed.
>
>The common case should be to support language x, y and z, and not
>wanting to change that, and never or rarely build binary packages (just
>as a backup before upgrade).
>This is how I believe Gentoo is used as a source based distribution.
>
>And big roll-outs with staging and binary packages have capable
>overlords knowing what's up in this area.
>
>As this idea is too obvious, I'm sure it has come up before and
>dismissed, but as I don't remember it mentioned in the previous thread,
>nor with a quick skim over them, here it is anyways.
>
>
>Mart


-- 
Best regards,
Michał Górny (by phone)

Reply via email to