Red Hat Bugzilla – Bug 10692
Problem with LINGUAS variable in build process
Last modified: 2007-04-18 12:26:34 EDT
If I build a package I expect to include all PO files (maybe sort them by
%lang macro). But building proces depend on environment variable LINGUAS.
Yes, I can unset this variable manually but sometime I forgot.
The solution is simple and logic: by default LINGUAS should be unset by rpm
itself. No one will wonder if setting LINGUAS to some value will be
explicitly needed in the SPEC file (this is correct as ALL actions needed
by build proces should be in this file).
Putting [ -z $LINGUAS ] || unset LINGUAS to the every spec file is bad as
number of applications with gettext growing every day and many applications
become gettextized so this seems to be wery anoying (and every developer
should keep on mind $LINGUAS).
Controlling for the environment is the responsibility of the packager, not
rpm. If you wish to do this "automagically", add
to the end of the %__build_pre macro definition.
Yes. But remember that *no* SPEC file from Red Hat, Inc. contain "unset LINGUAS"
thus many incomplete packages exist over the world (after recompiling etc). This
variable is a little bit special and *really* affect building of packages in bad
way. As a maintainer of our national (i18n) distribution I meet this problem
every day. Adding one line directly to the default RPM package will affect
nothig as every packager can *set* LINGUAS inside SPEC file if need it (and this
is special case, say 1% of all) and we will bles you.
Yes, after short time this will be unacceptable to install ALL locale files in
standard installation process and Anaconda will have selection for locales to be
installed (in future ofcourse). Thus variable LINGUAS will exist not only in
i18n region but in USA too. Keep in mind this and be prepared to do this logical
step now to make this process clean and without pain.
Adding "unset LINGUAS" to the end of %__build_pre can be easily done at any
time if necessary.
AFAIK this is no longer a problem, or at least I haven't heard of
a new complaint for quite some time.
I still suggest adding the one line to your build
system configuration, as I don't believe that rpm should
manage build system environment variables at all.
Thats mean that almost all of your spec files are broken because every spec
file have to unset problematic variables on its own.
Think about what is more easy or sane: do what is needed on one place or to
force everybody thinking about i18n things?
From that point of view it seems to me like rpm should make unified environment
(for i18n related things) and every package-maintainer should be forced to set
all what a package needs. Not to to this is very boken and mean that spec file
is not correct because building of a package depends on actual environment. I
suppse that spec files are there to make sure that any package could able
reproucible builded. And in this case it is not true a all.
I can imagine that rpm can print some warning messages too. But this is a
problem still that should be solved in some good and acceptable way.
Why I'm unable to reopen this bug?
At this time rpm sets LANG to C. So LINGUAS is the next logical step to protect
You are mistaken, rpm does not set LANG to C, although redhat-rpm-config
may very well be doing this.
The mechanism to change the environment of scriptlets
is easily extended to do whatever you wish, just like
See any of the %__spec_foo_pre macros, or the underlying
%___build_pre macro, in /usr/lib/rpm/macros for what needs