Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev@l.g.o, Mart Raudsepp <leio@g.o>
Subject: Re: [gentoo-dev] [RFC] Masterplan for solving LINGUAS problems
Date: Wed, 01 Jun 2016 13:10:12
Message-Id: 75E82000-6EC3-49EE-911C-7BEC39618257@gentoo.org
In Reply to: Re: [gentoo-dev] [RFC] Masterplan for solving LINGUAS problems by Mart Raudsepp
1 Dnia 1 czerwca 2016 11:18:30 CEST, Mart Raudsepp <leio@g.o> napisał(a):
2 >Ühel kenal päeval, T, 31.05.2016 kell 14:49, kirjutas Michał Górny:
3 >> Since the previous thread doesn't seem to have brought any good
4 >> solution to the problem other than stopping to (ab)use LINGUAS
5 >> as USE_EXPAND, I would like to start a RFC on a draft solution that
6 >> I'd like afterwards to propose to the Council.
7 >>
8 >>
9 >> Rationale
10 >> ---------
11 >>
12 >> The direct reason for this is that LINGUAS is treated as non-standard
13 >> special variable by multiple build systems. This includes the
14 >> following
15 >> problems:
16 >>
17 >> 1. no localizations are installed if it is set to an empty value
18 >> (which
19 >> happens in EAPI 5 when the ebuild does not use the flags),
20 >
21 >Why not just add a USE_EXPAND_DONTTOUCH variable to profiles, like
22 >there is already a USE_EXPAND_HIDDEN, which tells the PM to not play
23 >with the envvar, and just use it for USE expansion when the ebuild does
24 >use it?
25 >Point being, it leaves it unset, when it's unset, and it leaves it set
26 >to empty value or a value when it is so.
27 >
28 >Obviously with a better name than USE_EXPAND_DONTTOUCH, but you get the
29 >idea.
30
31 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.
32
33 >
34 >I suppose this doesn't solve the case of PM not knowing about what is
35 >inside a binary package, but if said variable also affected the
36 >metadata of the result, this should be possible to handled with some PM
37 >work, while not duplicating places to set languages to be
38 >compiled/installed.
39 >
40 >The common case should be to support language x, y and z, and not
41 >wanting to change that, and never or rarely build binary packages (just
42 >as a backup before upgrade).
43 >This is how I believe Gentoo is used as a source based distribution.
44 >
45 >And big roll-outs with staging and binary packages have capable
46 >overlords knowing what's up in this area.
47 >
48 >As this idea is too obvious, I'm sure it has come up before and
49 >dismissed, but as I don't remember it mentioned in the previous thread,
50 >nor with a quick skim over them, here it is anyways.
51 >
52 >
53 >Mart
54
55
56 --
57 Best regards,
58 Michał Górny (by phone)

Replies

Subject Author
Re: [gentoo-dev] [RFC] Masterplan for solving LINGUAS problems Dirkjan Ochtman <djc@g.o>