Bug 10692

Summary: Problem with LINGUAS variable in build process
Product: [Retired] Red Hat Linux Reporter: Milan Kerslager <milan.kerslager>
Component: rpm-buildAssignee: Jeff Johnson <jbj>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 9CC: mitr
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-02-10 19:18:19 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Milan Kerslager 2000-04-10 09:57:17 UTC
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).

Comment 1 Jeff Johnson 2000-04-13 11:07:59 UTC
Controlling for the environment is the responsibility of the packager, not
rpm. If you wish to do this "automagically", add
	unset LINGUAS
to the end of the %__build_pre macro definition.

Comment 2 Milan Kerslager 2000-07-03 13:52:52 UTC
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.

Comment 3 Jeff Johnson 2000-07-21 13:53:38 UTC
Adding "unset LINGUAS" to the end of  %__build_pre can be easily done at any
time if necessary.

Comment 4 Jeff Johnson 2001-02-21 18:57:17 UTC
Changing component.

Comment 5 Jeff Johnson 2001-07-25 21:29:22 UTC
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.

Comment 6 Milan Kerslager 2001-07-26 04:05:24 UTC
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?

Comment 7 Milan Kerslager 2001-07-26 04:07:43 UTC
c

Comment 8 Milan Kerslager 2003-05-24 09:50:27 UTC
At this time rpm sets LANG to C. So LINGUAS is the next logical step to protect
building process.

Comment 9 Jeff Johnson 2004-02-10 19:18:19 UTC
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
redhat-rpm-config.

See any of the %__spec_foo_pre macros, or the underlying
%___build_pre macro, in /usr/lib/rpm/macros for what needs
configuring.