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 unset LINGUAS 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.
Changing component.
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?
c
At this time rpm sets LANG to C. So LINGUAS is the next logical step to protect building process.
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.