3

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.

Improve this question
7

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.

Improve this answer
3
  • From time to time it is embarrassing to see such "obvious" solution and miss it oneself ;-) Thanks a lot! – greenoldman Dec 22 '12 at 15:30
  • How to use this if packages have versions too? E.g. package-1 = 1.0 – RedBaron Oct 14 '15 at 9:29
  • The same way: %define my_common_requires package-1 = 1.0, package-2 > 1.3, package-3 – Shishire Jan 20 '16 at 17:45
5

It seems, that

BuildRequires:  %{requires}

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

Improve this answer
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.

Improve this answer
5
  • 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 8: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 5: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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.