如何覆盖规范文件中的 CONFIG_SITE（最佳实践）
如果尝试从specfile构建rpm的用户在运行rpmbuild时在环境中设置了CONFIG_SITE，并且specfile使用“./configure --prefix=/usr && make”构建，则CONFIG_SITE中的用户设置可以完全破坏构建。 （作为一个具体的例子，假设 /usr/share/config.site 有一行“prefix=/bar”。那么，spec 文件的文件清单将完全错误，并且 rpmbuild 将失败。）
处理的最佳实践是什么这个问题？似乎常见的做法是忽略它。我决定在规范文件中设置 CONFIG_SITE=true ：
CONFIG_SITE=true ./configure --prefix=/usr ...
在调用 rpmbuild 时假设原始环境是否更常见，并且没有像在 /usr/share/config.site 中重置前缀那样的愚蠢行为？或者维护者是否负责确保规范文件将按预期构建 rpm？
If a user attempting to build an rpm from a specfile has CONFIG_SITE set in the environment when running rpmbuild, and the specfile builds with "./configure --prefix=/usr && make", then the user's settings in the CONFIG_SITE can completely mangle the build. (As a concrete example, suppose /usr/share/config.site has the line "prefix=/bar". Then the spec file's file manifest will be completely wrong and the rpmbuild will fail.)
What is the best practice for dealing with this issue? It seems like common practice is to ignore it. I've decided to set CONFIG_SITE=true in the specfile:
CONFIG_SITE=true ./configure --prefix=/usr ...
Is it more common to assume a pristine environment when invoking rpmbuild, and that there is no silliness like resetting prefix in /usr/share/config.site? Or is the maintainer responsible for ensuring that the spec file will build the rpm as expected?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为如果用户设置了一个愚蠢的 config.site 文件，那是他们自己的错。除了这个方法之外，肯定还有无数其他方法来破坏系统。我不会担心这个。我从未见过担心这一点的 rpm 或 deb 构建脚本。所以这可能是你的“最佳实践”。
您偶尔会看到，包带有自己的 config.site 文件，但通常由打包者提供该文件，以覆盖原始包中可能损坏的配置检查所产生的内容。
I think if users set up a stupid
config.sitefile, it's their own fault. There are certainly countless other ways besides this one to cripple a system; I wouldn't worry about it. I have never seen an rpm or deb build script that worries about this. So that's perhaps your "best practice".What you can see occasionally is that a package brings along its own
config.sitefile, but that is then usually supplied by the packager to override what a perhaps broken configure check in the original package would produce.