Ask Your Question

should subpackages have 'runtime' dependancy matching with toplevel package's 'runtime' dependancies?

asked 2017-09-27 07:26:26 -0500

For example,

If the top level package's spec file has a subpackage ,

-begin- . .

%package -n toplevel . Requires xyz >= 1.2.3 . .

%package subpackage . . Requires xyz . .


should xyz be >= 1.2.3 as per the top level constraint for the dependant package xyz ??

the runtime dependancies are captured using 'requires' statement..

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2017-09-28 14:28:09 -0500

FeRDNYC gravatar image

The guidelines are pretty clear:

Versioned dependencies (build-time or runtime) SHOULD ONLY be used when actually necessary to guarantee that the proper version of a package is present.

The subpackage should include the versioned dependency only if the subpackage requires a specific (or minimum) version to operate. It shouldn't include that Requires at all unless there are features of the subpackage that rely on the required package. And the top level package should only include the Requires line, with or without version, if there are features of the main package (without the subpackage) that genuinely require a specific/minimum version of the dependency, or requires it at all, in order to function.

Dependencies shouldn't "propagate" from main packages to subpackages, or vice versa. Specify only what applies to the immediate, innermost package level, and let the depsolver do its job. It's hopefully uncommon, but I can certainly imagine situations where a package requires a certain minimum version of a dependency, but its subpackage is fine with any available version, even a lower one. If that's the situation you have there, then spec it accordingly.

edit flag offensive delete link more

Question Tools

1 follower


Asked: 2017-09-27 07:26:26 -0500

Seen: 38 times

Last updated: Sep 28 '17