4

Let's say I have such Requires entries:

Requires: a
Requires: b
Requires: c

and now I would like to state, that:

BuildRequires: <<Requires>>

meaning, that for build I require everything that is required for install. So, if I remove or add something in the first section, I won't have to edit the second any more, because it will be "linked".

The question is -- how to express such dependency?

I know that such scheme is not good for public packages, but I am asking for home use -- I prepare quick packages for me and my family only, they are not distributed.

greenoldman
  • 6,176

3 Answers3

10

The easy answer is to define a macro which gets substituted into both locations.

%define my_common_requires package-1, package-2, package-3

BuildRequires: %{my_common_requires}
Requires:      %{my_common_requires}

This also lets you manually define something that needs to be in one of the two lines but not both.

TechyShishy
  • 116
  • 1
  • 4
5

It seems, that

BuildRequires:  %{requires}

"just works" -- at least, on RHEL6, where RPM is of version 4.8.0

Mikhail T.
  • 834
1

Let

  1. P be the name of your package;
  2. R1, R2, ..., Rn be its Requires
  3. RB1, RB2, ..., RBm be some its BuildRequires and R1, R2, ..., Rn be the other Requires.

Now you can

  1. Create a package PA with Requires R1, R2, ..., Rn that is otherwise empty.
  2. Edit P so that its Requires are PA and its BuildRequires are PA, RB1, RB2, ..., RBm

I am not convinced this is a good idea.

MyUsefulPackage
Requires: gcc
BuildRequires: gcc

becomes

MyUsefulPackage
Requires: MyUsefulRequires
BuildRequires: MyUsefulRequires

and

MyUsefulRequires
Requires: gcc

If I want to add another package make then it becomes: MyUsefulPackage Requires: MyUsefulRequires BuildRequires: MyUsefulRequires

and

MyUsefulRequires
Requires: gcc
Requires: make

It is not necessary to change the depends requirements of MyUsefulPackage. I can make just one change to MyUsefulRequires.

emory
  • 472
  • No-go. Once you have one Rx more, you have to add RBx too. So you actually made situation worse than before -- not only requirements are not dynamically linked, but now I have to deal with 2 specs. – greenoldman Jun 11 '12 at 08:37
  • I don't think so. I provided an example – emory Jun 11 '12 at 14:55
  • OK, you are right about single point of dependency but as you said, "I am not convinced this is a good idea." and I can say that too ;-) So I will wait for exact solution. – greenoldman Jun 12 '12 at 14:09
  • I meant I don't think linking the dependencies is a good idea (consequently my answer is also not a good idea). Is it really that hard to manually edit the spec file? What if you delete a Require dependency but it is still needed for the BuildRequire? – emory Jun 13 '12 at 05:00
  • This was just example -- in fact I am linking in reverse, whatever is in BuildRequires I would like to be in Requires as well. Editing is not that hard, but easy to miss something, and after all -- why NOT ask? Maybe there is a solution and this way I will be set for a lifetime. And linking dependencies in this particular context is very good idea IMHO :-) – greenoldman Jun 13 '12 at 16:31