Bug 1489548
Summary: | Make iproute-devel and iproute-doc depend on iproute | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Phil Sutter <psutter> |
Component: | iproute | Assignee: | Phil Sutter <psutter> |
Status: | CLOSED ERRATA | QA Contact: | Jaroslav Aster <jaster> |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | 7.5 | CC: | 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
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. 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 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 |