Bug 1325998

Summary: Cockpit is missing version-dependencies between subpackages
Product: [Fedora] Fedora Reporter: Stephen Gallagher <sgallagh>
Component: cockpitAssignee: Dominik Perpeet <dperpeet>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 25CC: dperpeet, stefw
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-04-05 07:21:39 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:

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.