| 1 |
Daniel Campbell posted on Tue, 31 May 2016 10:31:22 -0700 as excerpted: |
| 2 |
|
| 3 |
> I think this idea has some potential, but would there be a way for a |
| 4 |
> user to choose L10N *or* INSTALL_MASK instead of both? If I understand |
| 5 |
> correctly, a person who wanted all of their system to be en_US only, but |
| 6 |
> wanted to take part in translation of some other project, would need to |
| 7 |
> add the other locales directly to L10N, then somehow mask them out for |
| 8 |
> other packages. Or the reverse: leave L10N="en_US" or something, and |
| 9 |
> somehow enable other languages in that specific package. |
| 10 |
> |
| 11 |
> Is there a package-level option for this? Users can set their locales in |
| 12 |
> /etc/locale.gen, and that handles things globally, but what about the |
| 13 |
> user that doesn't want to include that for all of their packages? This |
| 14 |
> seems like an all-or-nothing thing, lacking in granularity. If I'm |
| 15 |
> wrong, please clarify so I can understand better. |
| 16 |
|
| 17 |
For portage at least, pretty much all vars, including the proposed L10N, |
| 18 |
can be set per-package using /etc/portage/package.env and the files it |
| 19 |
points to in /etc/portage/env/. |
| 20 |
|
| 21 |
(The package.env method works during the python phase as well, but is |
| 22 |
primarily for direct variable setting and isn't as flexible as the older |
| 23 |
/etc/portage/env/cat-egory/pkg/file method, which only works during the |
| 24 |
bash/ebuild phase, but exposes the full richness of bash to be used as |
| 25 |
it's actually bash executing it.) |
| 26 |
|
| 27 |
-- |
| 28 |
Duncan - List replies preferred. No HTML msgs. |
| 29 |
"Every nonfree program has a lord, a master -- |
| 30 |
and if you use the program, he is your master." Richard Stallman |
Archives