Bug 1325998 - Cockpit is missing version-dependencies between subpackages
Summary: Cockpit is missing version-dependencies between subpackages
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: cockpit
Version: 25
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
Assignee: Dominik Perpeet
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-04-11 14:30 UTC by Stephen Gallagher
Modified: 2017-04-05 07:21 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-04-05 07:21:39 UTC
Type: Bug


Attachments (Terms of Use)

Description Stephen Gallagher 2016-04-11 14:30:00 UTC
Description of problem:
This morning, I installed a Fedora 24 Server on bare metal, then decided to add several additional cockpit packages. The bare-metal install used the stable repository (containing Cockpit 0.99) and the dnf install also had the unstable repo available (this would also apply later to the frozen install repo and the updates repo). I ended up with a mixture of cockpit sub-packages with different versions.

Version-Release number of selected component (if applicable):
cockpit-sosreport-0.101-1.fc24.noarch
cockpit-bridge-0.99-1.fc24.x86_64
cockpit-selinux-0.101-1.fc24.noarch
cockpit-storaged-0.99-1.fc24.noarch
cockpit-shell-0.99-1.fc24.noarch
cockpit-ws-0.99-1.fc24.x86_64
cockpit-0.99-1.fc24.x86_64
cockpit-networkmanager-0.99-1.fc24.noarch
cockpit-docker-0.101-1.fc24.x86_64


How reproducible:


Steps to Reproduce:
1. See description

Actual results:
Various subpackages have mismatched versions and may not function properly together.

Expected results:
When installing a new subpackage that has a higher version, the existing packages should be updated to match.

Additional info:
This probably means playing around with `Conflicts: cockpit-foo != %{version}-%{release}` and `Requires: cockpit-bar = %{version}-%{release}` in each of the subpackages, so it will force the dependency resolver to look for a version of that other package that fits.

Comment 1 Dominik Perpeet 2016-04-15 08:56:21 UTC
Thanks for catching this, Stephen.

Since the API isn't yet stable, most packages should indeed ensure that others are of the same version. Some, cockpit-ws comes to mind, are sufficiently stable that different versions shouldn't be an issue.

We'll look into this and update the dependencies!

Comment 2 Stephen Gallagher 2016-04-15 13:03:24 UTC
(In reply to Dominik Perpeet from comment #1)
> Thanks for catching this, Stephen.
> 
> Since the API isn't yet stable, most packages should indeed ensure that
> others are of the same version. Some, cockpit-ws comes to mind, are
> sufficiently stable that different versions shouldn't be an issue.
> 
> We'll look into this and update the dependencies!

Even if they are *compatible*, it's certainly in our users' best interests if they still maintain the same versions anyway. It would be very confusing (and perhaps concerning) if only some pieces of the cockpit service were on the latest bits.

See https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#Requiring_Base_Package

Comment 3 Stephen Gallagher 2016-09-22 18:11:22 UTC
*bump*

Just going through old tickets; did this ever get fixed?

Comment 4 Stef Walter 2016-09-23 19:40:57 UTC
I think so. Dominik could confirm.

Comment 5 Dominik Perpeet 2017-04-05 07:21:39 UTC
This got fixed a while ago, but recently we clarified the dependencies a bit further.
It's still possible and viable to have different versions of packages, but they are properly marked to "require" their actual dependencies (e.g. cockpit-selinux requires a bridge >= 122). The package cockpit-ws isn't tied to a specific bridge, but that's because it can also be shipped in a container and can work without a bridge.


Note You need to log in before you can comment on or make changes to this bug.