Ühel kenal päeval, K, 01.06.2016 kell 12:18, kirjutas Mart Raudsepp: > Ü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. > > 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. >
That said, I didn't like this being made a USE_EXPAND from the start, as it does something else - control what huge language packs get installed, as opposed to what stripping of files and file contents is done. And LINGUAS is quite a different beast, due to dialects, having special rules of implicit handling (e.g, you have a dialect in LINGUAS, but no specific translations exist for that language, you still get the main one instead; or was it vice-versa). But I don't think we need to wait for the INSTALL_MASK bits to swap the USE_EXPAND over to L10N or some other name (maybe something that denotes likely extra downloads of langpacks). We still have LINGUAS, which we might want to document better (with the binary package caveats mentioned, etc), and localepurge that end results in the same result as with the proposed INSTALL_MASK. Though this shouldn't demotivate to make this group feature for INSTALL_MASK happen regardless. The lingua groups should probably be with wildcards like <path>/pl/... AND <path>/pl_*/... to cover dialects, when you don't have dialect groups. Additionally I don't think there's harm in filtering languages out manually based on LINGUAS after all this is done still (LINGUAS not being a USE_EXPAND), if the upstream build system itself doesn't. Might want to take more care about dialects though. ` Mart
