Linux RPM 规范文件可以“包含”其他文件吗？

can an RPM spec file "include" other files?

提问by davka

Is there a kind of "include" directive in RPM spec? I couldn't find an answer by googling.

RPM 规范中是否有一种“包含”指令？我无法通过谷歌搜索找到答案。

Motivation: I have a RPM spec template which the build process modifies with the version, revision and other build-specific data. This is done by sedcurrently. I think it would be cleaner if the spec would #includea build-specific definitions file, which would be generated by the build process, so I don't need to search and replace in the spec.

动机：我有一个 RPM 规范模板，构建过程会根据版本、修订版和其他特定于构建的数据对其进行修改。这是sed目前完成的。我认为如果规范#include是由构建过程生成的特定于构建的定义文件会更清晰，所以我不需要在规范中搜索和替换。

If there is no include, is there an idiomatic way to do this (quite common, I believe) task?

如果没有include，是否有一种惯用的方法来完成这个（我相信很常见）任务？

采纳答案by m1tk4

RPM does not support includes.

RPM 不支持包含。

I have solved similar problems with either m4 macro processor or by just concatenating parts of spec (when the "include" was at the beginning).

我已经用 m4 宏处理器或通过连接规范的部分（当“包含”在开头时）解决了类似的问题。

If you only need to pass a few variables at build time, and not include several lines from another file, you can run

如果你只需要在构建时传递几个变量，而不包括来自另一个文件的几行，你可以运行

rpmbuild --define 'myvar SOMEVALUE' -bb myspec.spec

and you can use %myvar in the spec.

并且您可以在规范中使用 %myvar。

回答by digitalsky

Which version are you talking about? I currently have %include filename.txt in my spec file and it seems to work just like the C #include directive.

你说的是哪个版本？我目前在我的规范文件中有 %include filename.txt ，它似乎就像 C #include 指令一样工作。

> rpmbuild --version
RPM version 4.8.1

回答by М?ша

Sufficiently recent versions of rpmbuild certainly do support %include:

最新版本的 rpmbuild 肯定支持 %include：

%include common.inc

Unfortunately, they aren't very smart about it -- there is no known set of directories, in which it will look for the requested files, for example. But it is there and variables are expanded, for example:

不幸的是，他们对此并不是很聪明——例如，没有已知的目录集，它将在其中查找请求的文件。但它在那里并且变量被扩展，例如：

%include %{_topdir}/Common/common.inc

回答by marcindulak

You can include the *.incfiles from the SOURCES directory (%_sourcedir):

您可以包含*.inc来自 SOURCES 目录 ( %_sourcedir)的文件：

Source1: common.inc

%include %{SOURCE1}

In this way they will go automatically into SRPMS.

这样，它们将自动进入SRPMS。

回答by artless noise

For the underlying issue, there maybe two additional solutions that are present in all rpmversions that I am aware of.

对于潜在的问题，我所知道的所有rpm版本中可能都存在两个额外的解决方案。

1. Subpackages
2. macroand rpmrcfiles.

1. 子包
2. macro和rpmrc文件。

Subpackages

子包

Another alternative (and perhaps the "RPM way") is to use sub-packages. Maximum RPMalso has information and examples of subpackages.

另一种选择（也许是“ RPM 方式”）是使用子包。最大 RPM还包含子包的信息和示例。

I think the question is trying to structure something like,

我认为问题是试图构建类似的东西，

• two spec files; say rpm_debug.specand rpm_production.spec
• both use %include common.spec

• 两个规范文件；说rpm_debug.spec和rpm_production.spec
• 两者都使用 %include common.spec

debugand productioncould also be clientand server, etc. For the examples of redefining a variable, each subpackagecan have it's own list of variables.

debug和production也可以是client和server等。对于重新定义变量的例子，每个子包都可以有它自己的变量列表。

Limitations

限制

The main advantage of subpackagesis that only one buildtakes place; This may also be a disadvantage. The debugand productionexample may highlight this. That can be worked around using stripto create variants orcompiling twice with different output; perhaps using VPATHwith Gnu Make). Having to compile large packages and then only have simple variations, like with/without developer info, like headers, static libraries, etc. can make you appreciate this approach.

子包的主要优点是只进行一次构建；这也可能是一个缺点。在调试和生产例如可以强调这一点。这可以通过使用strip来创建变体或使用不同的输出编译两次来解决；也许VPATH与 Gnu Make 一起使用）。不必编译大包，然后只需要简单的变化，比如有/无开发人员信息，比如headers，静态库等，可以让你欣赏这种做法。

Macros and Rpmrc

宏和 Rpmrc

Subpackagesdon't solve the problem of structuraldefines that you wish for an entire rootfshierarchy, or larger collection of RPMs. We have rpmbuild --showrcfor this. You can have a large amount of variablesand macrosdefined by altering rpmrcand macroswhen you run rpmand rpmbuild. From the manpage,

子包不能解决您希望整个rootfs层次结构或更大的 RPM 集合的结构定义问题。我们有这个。你可以有大量的变量和宏通过改变规定，并在运行和。从页面，rpmbuild --showrcrpmrcmacrosrpmrpmbuildman

   rpmrc Configuration
       /usr/lib/rpm/rpmrc
       /usr/lib/rpm/redhat/rpmrc
       /etc/rpmrc
       ~/.rpmrc

   Macro Configuration
       /usr/lib/rpm/macros
       /usr/lib/rpm/redhat/macros
       /etc/rpm/macros
       ~/.rpmmacros

I think these two features can solve all the problems that %includecan. However, %includeis a familiar concept and was probably added to make rpmmore full-featured and developer friendly.

我认为这两个功能可以解决所有可以解决的问题%include。然而，这%include是一个熟悉的概念，可能是为了使rpm 功能更全面和对开发人员友好而添加的。

回答by Aaron D. Marasco

I've used scripts (name your favorite) to take a template and create the spec file from that. Also, the %filestag can import a file that is created by another process, e.g. Python's bdist-rpm.

我使用脚本（命名您最喜欢的）来获取模板并从中创建规范文件。此外，该%files标签可以导入由另一个进程创建的文件，例如 Python 的bdist-rpm.

回答by Bob Bell

I faced this same issue recently. I wanted to define multiple sub-packages that were similar, but each varied just slightly (they were language-specific RPMs). I didn't want to repeat the same boiler-plate stuff for each sub-package.

我最近遇到了同样的问题。我想定义多个相似的子包，但每个子包都略有不同（它们是特定于语言的 RPM）。我不想为每个子包重复相同的样板内容。

Here's a generic version of what I did:

这是我所做的通用版本：

%define foo_spec() %{expand:%(cat '%{myloc}/main-foo.spec')}
%{foo_spec bar}
%{foo_spec baz}
%{foo_spec qux}

The use of %{expand}ensures that %(cat)is only executed a single time, when the macro is defined. The content of the main-foo.spec file is then three times, and each time %1in the main-foo.spec file expands to each of bar, bazand qux, in turn, allowing me to treat it as a template. You could easily expand this to more than one parameter, if you have the need (I did not).

使用%{expand}可确保%(cat)仅在定义宏时执行一次。main-foo.spec 文件的内容然后是三倍，并且每次%1在 main-foo.spec 文件中扩展到每个bar,baz和qux，反过来，允许我将其视为模板。如果需要（我没有），您可以轻松地将其扩展为多个参数。