Re: [gentoo-dev] RFC: storing predefined INSTALL_MASK directory lists in repos

[Alan McKinnon <alan.mckinnon@gmail.com>]

On 11/01/2014 18:52, Michał Górny wrote:
> Dnia 2014-01-11, o godz. 18:15:09
> Alan McKinnon <alan.mckinnon@gmail.com> napisał(a):
> 
>> A far better method from a user point of view is to install the linguas
>> the user explicitly asked for. Your proposal as worded will be taken at
>> first glance to mean "install all linguas, but not XX" as most users
>> won't see the MASK portion and forget to flip the logic around in their
>> head.
> 
> As said on the other mail, I think we could just make portage
> implicitly convert LINGUAS into INSTALL_MASK. That is, use the old
> variable and give it a bit of new behavior.

Do you mean retain LINGUAS in make.conf and remove it from "emerge -p"
output?

I don't know much about how LINGUAS works behind the scenes, but you
seem to be proposing a scheme that works something like this:

1. User specifics what LINGUAS they want in make.conf
2. Portage magically and invisibly installs files only for that LINGUA

That seems a good approach, it unclutters emerge -p output [the amount
of clutter that causes, together with APACHE2_MODULES, CAMERAS,
PHP_MODULES etc is quite unbelievable] and gives the user what they
asked for. If you hide the negative logic in the implementation that is
double bonus

> 
>> How much work is it to get native support for LINGUAS into all ebuilds?
>> That would be the intuitive place considering there is already USE flags
>> for LINGUAS.
> 
> Honestly? I'm all limbs against LINGUAS in its current form. It's just
> extra dumb.
> 
> We have basically two cases:
> 
> 1. packages that make LINGUAS into USE flags and use them to control
> l10n. It's just useless extra work and extra rebuilds for locale
> change.
> 
> 2. packages that respect LINGUAS implicitly. That is, install only some
> of the files silently and you don't even know which were enabled.
> 
> install-mask provides a clean framework to strip linguas with
> binpackage friendliness potential.
> 


-- 
Alan McKinnon
alan.mckinnon@gmail.com