[gentoo-dev] Re: LINGUAS handling
Harald van Dijk posted on Wed, 09 Jun 2010 21:21:44 +0200 as excerpted:
> Firstly, don't use == with test. It's not portable. The bash built-in
> test supports ==. Other test implementations don't, such as the one from
> GNU coreutils, and the built-in test in other shells, don't. If you use
> test in a context where you're absolutely sure the built-in version will
> be used, and the executing shell is bash, then I suppose you can use ==,
> but at that point you're better off using [[ ]] anyway.
Good point about [[ ]].
> That said, to test if a variable is set, use ${VAR+set} over
> ${VAR-unset}. ${VAR-unset} evaluates to "unset" if VAR is unset, and if
> VAR is set to the string "unset". I suppose that's why you used %UNSET%,
> to reduce the possibility of accidents. You can reduce it to 0, using
> for example
>
> if [[ -z ${LINGUAS+set} ]]; then
> # LINGUAS is unset
> fi
While we're talking style, a question (well, a couple):
I've seen code like that posted frequently, but always wonder why the -z
is even used at all. Also, why use the if/then form? Is that Gentoo
style guidelines (like always using the brace-var form apparently is,
${LINGUAS} vs. $LINGUAS)? Why not simply (: instead of # to avoid an
empty subshell):
[[ ${LINGUAS} ]] || {
: LINGUAS is unset
}
>> If yes, it's easy to write such code and put in eclass. If no, how do
>> we live with inconsistency that some packages will install all
>> languages some, will install nothing (document in handbook and add
>> portage warning in case LINGUAS is unset?)?
>
> Unfortunately, consistency either way is bad. Making unset LINGUAS
> install nothing changes gettext's design, when the whole idea behind
> LINGUAS was to mimic gettext's design. Making unset LINGUAS install
> everything causes massive disk space requirements for the default
> settings for some packages such as openoffice. In my opinion, either of
> those would be worse than having LINGUAS behave inconsistently.
++
>> 3. What is the purpose of strip-linguas function
> It's used for some packages that fail to build with certain LINGUAS
> values. If I recall correctly, binutils had a bug where putting en_GB in
> your LINGUAS made the build fail, for example. binutils doesn't support
> en_GB anyway, so it gets filtered out,
Here's a simple question I've wondered for awhile, not documented anywhere
I could find, but should be.
What do those of us who only speak English (whatever form, US is fine) put
in LINGUAS, to ensure no "extras" we can't use anyway get installed?
Currently, I have in one of my make.conf include files: LINGUAS="en",
hoping to avoid the "everything installed" scenario above. But then on
binutils, I get the message "en" is not supported, which is fine, it
works, but with it stripped, does that mean it's installing unnecessary
language stuff that's of no use to me anyway? Should it be "en_US" or
"en_US.UTF-8" instead? Or maybe it should be simply "C"?
A line or two in the l10n guide, plus possibly the handbook, telling what
to set if "plain English" is "plain OK" to avoid the "unset installs it
all" problem, would be useful.
And if there is no such single value available presently, as looks likely,
how big a project would it be to add it? Or perhaps an alternate
approach, a table of packages and the setting to be added to a file in
/etc/portage/env (or whatever), would be more appropriate? I haven't a
clue on this. Perhaps all I need is pointed at the right documentation,
but if so, that "right documentation" should probably be a bit more
visible, as I've certainly looked.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] app-editors/vim and USE="vim-with-x" -> Rename to USE="X"?
Mike Frysinger wrote: > people want it and i havent seen any compelling reason to avoid it > anymore, so let's rock For the record: It is now rocked. -- Jim Ramsay Gentoo Developer (rox/fluxbox/gkrellm/vim) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Packages up for grabs -- xmerlin, yoswink, chtekk, omp, tantive, mueli, bluebird, hncaldwell, caleb
On Tue, 8 Jun 2010 21:59:11 +0200 José María Alonso wrote: > On Tue, Jun 08, 2010 at 06:25:17PM +0200, Jeroen Roovers wrote: > > On Tue, 8 Jun 2010 13:14:07 +0200 > > José María Alonso wrote: > > > > > I would be very pleased to maintain this package: > > > > > > > app-doc/repodoc > > > > > Is there any chance I can maintain this package?. What do > > > I have to do?. > > > > You could provide unified patches to the ebuilds to fix the four > > outstanding bugs[1] with the package. Someone should CC themselves > > on those bugs who has commit access for the thing to work, of > > course. Maybe the live (-) ebuild could use some work too. > > > > > > [1] https://bugs.gentoo.org/buglist.cgi?quicksearch=repodoc > > > > Thank you very much for pointing me in the right direction. > I'll begin to work in those bugs. > I can be your proxy commmiter for this one, perhaps a starting point is to update the home page[2] of this package; actually I don't know if it is still developed. Ping me when you have some news :) [2] http://dev.gentoo.org/~yoswink/repodoc/ Regards, -- Víctor Ostorga Gentoo Linux developer (lxde, treecleaners) http://www.gentoo.org signature.asc Description: PGP signature
Re: [gentoo-dev] LINGUAS handling
On Wed, Jun 09, 2010 at 11:38:03AM +0400, Peter Volkov wrote:
> 1. Do we want all packages to support LINGUAS if possible? It is
> possible to leave gettext based package without LINGUAS and everything
> will just work, but I think that it's good idea to make supported
> languages visible to user through linguas_ flags.
I agree, but I'd like to point out this would be a visible change in
default behaviour: the default would change from "install everything" to
"install nothing". For gettext-based packages, "install everything" is a
sane default, in my opinion.
> 2. How should we handle case of unset LINGUAS in ebuild? Should we mimic
> gettext and install all supported languages, using code like
>
> LINGUAS=${LINGUAS-%UNSET%}
> if test "%UNSET%" == "$LINGUAS"; then
> # install all supported languages
> fi
Firstly, don't use == with test. It's not portable. The bash built-in
test supports ==. Other test implementations don't, such as the one from
GNU coreutils, and the built-in test in other shells, don't. If you use
test in a context where you're absolutely sure the built-in version will
be used, and the executing shell is bash, then I suppose you can use ==,
but at that point you're better off using [[ ]] anyway.
That said, to test if a variable is set, use ${VAR+set} over
${VAR-unset}. ${VAR-unset} evaluates to "unset" if VAR is unset, and if
VAR is set to the string "unset". I suppose that's why you used %UNSET%,
to reduce the possibility of accidents. You can reduce it to 0, using
for example
if [[ -z ${LINGUAS+set} ]]; then
# LINGUAS is unset
fi
> ? If yes, it's easy to write such code and put in eclass. If no, how do
> we live with inconsistency that some packages will install all languages
> some, will install nothing (document in handbook and add portage warning
> in case LINGUAS is unset?)?
Unfortunately, consistency either way is bad. Making unset LINGUAS
install nothing changes gettext's design, when the whole idea behind
LINGUAS was to mimic gettext's design. Making unset LINGUAS install
everything causes massive disk space requirements for the default
settings for some packages such as openoffice. In my opinion, either of
those would be worse than having LINGUAS behave inconsistently.
> 3. What is the purpose of strip-linguas function (mentioned in
> devmanual)? It's clear what it does but I have no ideas why. Probably
> similar code could be used in QA function that will gather supported
> languages from po directories and warn maintainer that it's time to
> update linguas_ in IUSE (and probably later it could be expanded
> to support qt packages too).
It's used for some packages that fail to build with certain LINGUAS
values. If I recall correctly, binutils had a bug where putting en_GB in
your LINGUAS made the build fail, for example. binutils doesn't support
en_GB anyway, so it gets filtered out,
Re: [gentoo-dev] RFC: changing the developer profile: FEATURES="test" -> FEATURES="test-fail-continue"
On 6/4/10 5:11 PM, "Paweł Hajdan, Jr." wrote: > What do you think about doing the following change in > /usr/portage/profiles/targets/developer/make.defaults: The following change has now landed in CVS: Index: targets/developer/make.defaults === RCS file: /var/cvsroot/gentoo-x86/profiles/targets/developer/make.defaults,v retrieving revision 1.3 retrieving revision 1.4 diff -u -B -r1.3 -r1.4 --- targets/developer/make.defaults 4 Oct 2009 09:44:27 - 1.3 +++ targets/developer/make.defaults 9 Jun 2010 17:03:37 - 1.4 @@ -1,8 +1,8 @@ # Copyright 1999-2008 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 -# $Header: /var/cvsroot/gentoo-x86/profiles/targets/developer/make.defaults,v 1.3 2009/10/04 09:44:27 ssuominen Exp $ +# $Header: /var/cvsroot/gentoo-x86/profiles/targets/developer/make.defaults,v 1.4 2010/06/09 17:03:37 phajdan.jr Exp $ -FEATURES="collision-protect cvs digest multilib-strict sign splitdebug stricter test userpriv usersandbox" +FEATURES="collision-protect cvs digest multilib-strict sign splitdebug stricter test test-fail-continue userpriv usersandbox" # Disable branding (from desktop) USE="-branding" signature.asc Description: OpenPGP digital signature
[gentoo-dev] LINGUAS handling
Hi.
We have LINGUAS support in portage for quite some time now, but how do
we handle LINGUAS? It's not as evident as it seems and thus we need some
guidelines. So I'll formulate few questions below but first let's look
how portage works with LINGUAS. If you know this skip to Questions
section below.
Portage/gettext
---
Like USE variable LINGUAS value could be set by user in /etc/make.conf,
package.keywords or environment. There are three different cases: 1)
LINGUAS set to some value, 2) LINGUAS set and contains '*'[1] 3) LINGUAS
unset. portage will treat this cases differently for ebuilds with
linguas_ in IUSE and without. This makes 6 cases:
1. In case LINGUAS is set and ebuild has no linguas_ in IUSE
portage exports LINGUAS as is.
2. In case LINGUAS is set and IUSE contains linguas_ portage
exports intersection of languages in LINGUAS and IUSE. E.g. LINGUAS set
to "lang1 lang2" and IUSE contains "linguaus_ linguaus_"
portage will export LINGUAS="lang1".
3. In case LINGUAS contains '*' and there is no linguaus_ in IUSE
portage unsets LINGUAS.
4. In case LINGUAS contains '*' and IUSE contains linguas_ portage
exports LINGUAS with langs defined in the IUSE's linguas_.
5. If LINGUAS is unset and ebuild has no linguas_ flag portage
unsets LINGUAS.
6. In case LINGUAS is unset and IUSE contains linguas_ portage
exports LINGUAS="".
|ebuild contains linguas_ the IUSE |
--|
| no |yes|
---
LINGUAS unset |LINGUAS unset|LINGUAS='' |
--|
LINGUAS has '*' |LINGUAS unset| LINGUAS='lang' |
---
LINGUAS set |LINGUAS set literally|LINGUAS set to intersection|
| |of lang in IUSE and LINGUAS|
---
BTW, I guess all above is applicable to all USE_EXPANDED variables.
But unlike other variables LINGUAS is used by gettext and in case it is
unset gettext installs all translations.
Questions
-
1. Do we want all packages to support LINGUAS if possible? It is
possible to leave gettext based package without LINGUAS and everything
will just work, but I think that it's good idea to make supported
languages visible to user through linguas_ flags.
2. How should we handle case of unset LINGUAS in ebuild? Should we mimic
gettext and install all supported languages, using code like
LINGUAS=${LINGUAS-%UNSET%}
if test "%UNSET%" == "$LINGUAS"; then
# install all supported languages
fi
? If yes, it's easy to write such code and put in eclass. If no, how do
we live with inconsistency that some packages will install all languages
some, will install nothing (document in handbook and add portage warning
in case LINGUAS is unset?)?
3. What is the purpose of strip-linguas function (mentioned in
devmanual)? It's clear what it does but I have no ideas why. Probably
similar code could be used in QA function that will gather supported
languages from po directories and warn maintainer that it's time to
update linguas_ in IUSE (and probably later it could be expanded
to support qt packages too).
[1] or equivalently linguas_* is set in package.use
--
Peter.
