Bug 1489548

Summary: Make iproute-devel and iproute-doc depend on iproute
Product: Red Hat Enterprise Linux 7 Reporter: Phil Sutter <psutter>
Component: iprouteAssignee: Phil Sutter <psutter>
Status: CLOSED ERRATA QA Contact: Jaroslav Aster <jaster>
Severity: low Docs Contact:
Priority: low    
Version: 7.5CC: atragler, jaster, psutter
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: iproute-4.11.0-7.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-04-10 14:31:17 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Phil Sutter 2017-09-07 17:10:41 UTC
These derived packages should depend on the base one to make sure they stay in sync.

Comment 4 Jaroslav Aster 2017-12-19 15:45:28 UTC
Hi Phil,

is there any guideline what package should depends on main package and what package not?

I'm confused. Ok, iproute-devel and iproute-doc now depend on iproute in the same version. It seems ok, but why not iproute-debuginfo? It is still possible to install iproute-debuginfo in different version than iproute. Does it make sense? Does it make sense to install iproute-devel or iproute-doc without iproute? I can imagine, in some cases, yes, for example I would like to read doc before install main package.

But in the same time, it does not make sense to have main and sub packages in different version installed on the system. Is it possible to do this:

Sub package does not depends on main package or any other sub package, but in the same time is not possible to mix version of installed packages.

Comment 5 Phil Sutter 2017-12-19 22:17:54 UTC
Hi Jaroslav,

(In reply to Jaroslav Aster from comment #4)
> is there any guideline what package should depends on main package and what
> package not?

The only thing I found is this:
https://fedoraproject.org/wiki/Packaging:Guidelines#Requiring_Base_Package

But it really doesn't make sense to make the base package depend on it's
subpackages: If it did, you would automatically pull in all subpackages when
installing the base one. This effectively defeats the benefit of having
subpackages, namely to allow users to e.g. not install extra documentation if
they are not interested in that.

> I'm confused. Ok, iproute-devel and iproute-doc now depend on iproute in the
> same version. It seems ok, but why not iproute-debuginfo? It is still
> possible to install iproute-debuginfo in different version than iproute.
> Does it make sense? Does it make sense to install iproute-devel or
> iproute-doc without iproute? I can imagine, in some cases, yes, for example
> I would like to read doc before install main package.

The debuginfo package is created automatically, I don't specify it explicitly
in spec file. Therefore I can't control what it depends on.

> But in the same time, it does not make sense to have main and sub packages
> in different version installed on the system. Is it possible to do this:
> 
> Sub package does not depends on main package or any other sub package, but
> in the same time is not possible to mix version of installed packages.

No, that's not possible. Package dependencies is all we have, and they are not
flexible enough for something like that.

But honestly, I think you're trying to over-engineer this a bit. How often did
you really install package foo-doc to read the docs before installing package
foo? If you want to use package foo, then you would install it right away and
then maybe opt for foo-doc if the shipped man page is not elaborate enough.

In fact, many packages don't have subpackage dependencies in place. It's not
critical simply because people usually call 'yum update' and fetch the latest
version of everything they have installed. :)

Cheers, Phil

Comment 9 errata-xmlrpc 2018-04-10 14:31:17 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2018:0815