0
votes

I never worked with rpm spec files before so the answer can be quite obvious. My custom rpm has several versions to simplify let it be 1.0.0 and 2.0.0. For example, it can work with or without packageA but if packageA is installed for version 2.0.0 it should be at least 7.0.0. For testing purposes I create hello-world.spec file.

$cat hello.spec
[mylaptop]# cat ~/hello.spec 
Name:       hello-world
Version:    1
Release:    1
Summary:    Most simple RPM package
License:    FIXME
%define packageA_installed %(rpm -qa packageA-client)

 
%define version 2.2.0


%if "%packageA_installed"
%global with_packageA 1
# just for test purpose it will be deleted after testing and I will only set with_packageA
Requires: packageA-client == 1
%else
# just for test purpose it will be deleted after testing and I will only set with_packageA 
Requires: packageA-client == 0
%global with_packageA 0
%endif

# I need check if packageA is installed and current rpm version 2.2.0
%if "%with_packageA" == "1" && "%{version}" == "2.2.0"
#if true - for 2.2.0 can work only with 7.0.0 and higher packageA
Requires: packageA-client >= 7.0.0
%endif
.......

On the system where packageA-client is installed:

[mylaptop(with packageA-client)]# rpm -qa packageA-client 
packageA-client-7.0.0-93073D.RedHat7.x86_64
[mylaptop(with packageA-client)]# rpm -i hello-world-1-1.x86_64.rpm 
error: Failed dependencies:
      packageA-client = 1 is needed by hello-world-1-1.x86_64

It means that packageA-client was found and error is expected

Then I try to run the same on the system where is packageA-client is not installed:

[mylaptop(without packageA-client)]# rpm -qa packageA-client
[mylaptop(without packageA-client)]# rpm -i ~/hello-world-1-1.x86_64.rpm 
error: Failed dependencies:
    packageA-client = 1 is needed by hello-world-1-1.x86_64
    packageA-cllent >= 7.0.0 is needed by hello-world-1-1.x86_64
[mylaptop(without packageA-client)]#

I expect that error will be packageA-client = 0 is needed by hello-world-1-1.x86_64 since it should go to the else condition because if not true since packageA-client was not found. What is wrong here and what is the right way to implement logic like this.

2
This seems backwards. You add the Requires tag to ensure that packageA is installed. If you can install the package without packageA, you don't have a requirement. That is, whether or not hello-world depends on packageA does not depend on whether packageA is already installed or not. What are you really trying to accomplish here? - chepner
If you are just trying to enforce that packageA-client be installed if packageA is installed, that makes a little more sense, though I'm not sure Requires is the best way to manage it. What should happen if you install hello-world first without packageA being installed, then subsequently install packageA? - chepner
@chepner maybe I really overcomplicated things but I simply need to do something like this if (packageA == installed && version == 2.2.0) then packageA should be at least 7.0.0. Regards your second question the same logic should be done for packageA if hello-world is installed and it version 2.2.0 the we should not allow packageA installation lower then 7.0.0. - Nick S
I think Conflicts: packageA < 7.0.0 will handle that case, but there's still the issue of making the packageA-client requirement depend on the presence of packageA. - chepner
@chepner It seems that I confused you with the naming. packageA is the same as packageA-client. I simply trim client in the naming of variable... to not write it like with_packageA-client Thank you for answer I will try Conflicts: - Nick S

2 Answers

2
votes

The Conflicts tag may be what you are looking for:

Conflicts: packageA < 7.0.0

This will only block installation if packageA is installed and is older than 7.0.0. Further, it will not cause packageA to be installed if it isn't already.

I believe it will also prevent an older version of packageA from being installed after hello-world is installed.

-1
votes

See if there is a virtual "provides" that includes the overall functionality. If there is, require it.

Then put in a conflicts directive with the packages, using version scopes, to avoid the provding packages that are at the wrong version number.

By declartively defining the requires and conflicts, your logic will be handled by the resolver (part of the solver engine) This means that your package won't have to be in the middle of being installed to run it's logic, and the logic will work correctly with a wider range of scenarios (and fail outside of "whatever was put in this package")