Bug 10692
Summary: | Problem with LINGUAS variable in build process | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Milan Kerslager <milan.kerslager> |
Component: | rpm-build | Assignee: | Jeff Johnson <jbj> |
Status: | CLOSED WONTFIX | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 9 | CC: | 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
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. |