Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 111328 - store LINGUAS (openoffice) for later emerge
Summary: store LINGUAS (openoffice) for later emerge
Status: RESOLVED DUPLICATE of bug 44796
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Gentoo Linux bug wranglers
Depends on:
Reported: 2005-11-03 01:28 UTC by Nguyen Thai Ngoc Duy (RETIRED)
Modified: 2005-11-03 07:57 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Nguyen Thai Ngoc Duy (RETIRED) gentoo-dev 2005-11-03 01:28:39 UTC
Sorry if the summary is not clear. Here is my problem. I would like to emerge
openoffice with vi support. openoffice requires LINGUAS set to "vi" to be able
to build with vi support. This is not good because when i upgrade openoffice,
LINGUAS is not set and the result is openoffice without vi support.
I would like something like /etc/portage/package.env that behaves similar to
/etc/portage/package.use. The difference is that it used to store environment
variables for specified ebuilds. I may probably use /etc/portage/bashrc (not
tried yet) but i don't want to set LINGUAS for every ebuilds just because i need
it for openoffice.
/etc/portage/package.env's content would be:
=app-office/openoffice-2* LINGUAS="en vi"
Comment 1 Harald van Dijk (RETIRED) gentoo-dev 2005-11-03 02:17:11 UTC
As a workaround in this specific case, you can put

[[ ${CATEGORY}/${P} == app-office/openoffice-2* ]] &&
    export LINGUAS="en vi"

in your /etc/portage/bashrc. This is not a panacea - it won't work with ebuilds
which use linguas_## USE variables instead of LINGUAS directly, for example -
but it should work with openoffice with the LINGUAS you want. Bug #44796
contains a pointer to a simple bashrc which does some extra work allowing you do
specify this in a way somewhat similar to how you describe it, but with the same

*** This bug has been marked as a duplicate of 44796 ***