Bug 10692 - Problem with LINGUAS variable in build process
Problem with LINGUAS variable in build process
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: rpm-build (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-04-10 05:57 EDT by Milan Kerslager
Modified: 2007-04-18 12:26 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-02-10 14:18:19 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Milan Kerslager 2000-04-10 05:57:17 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).
Comment 1 Jeff Johnson 2000-04-13 07:07:59 EDT
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 09:52:52 EDT
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 09:53:38 EDT
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 13:57:17 EST
Changing component.
Comment 5 Jeff Johnson 2001-07-25 17:29:22 EDT
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 00:05:24 EDT
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 00:07:43 EDT
c
Comment 8 Milan Kerslager 2003-05-24 05:50:27 EDT
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 14:18:19 EST
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.

Note You need to log in before you can comment on or make changes to this bug.