Bug 2254254 - Containers-common should have versions
Summary: Containers-common should have versions
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: containers-common
Version: rawhide
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Lokesh Mandvekar
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-12-12 20:56 UTC by Troy Dawson
Modified: 2024-01-19 13:12 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2024-01-19 13:12:21 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Troy Dawson 2023-12-12 20:56:19 UTC
The containers-common package currently has no version.  It is version 1.
The problem is that the fedora package for it uses rpmautospec, so the releases are automatically generated.
This causes problems when build systems (such as Brew) who don't have the ability to use rpmautospec build the package.  Other packages, such as skopeo require conntainers-common >= 1-21, and if you can't detemine what release you are on, then skopeo can't be installed.

In short, you can not change the version, or you can use rpmautospec, but if you do both then chaos reigns.

Note: This is blocking CentOS Stream 10 and RHEL 10 development.

Reproducible: Always

Steps to Reproduce:
1.Setup a machine to utilize CS10
https://composes.stream.centos.org/stream-10/odcs-4257/compose/BaseOS/x86_64/os/
https://composes.stream.centos.org/stream-10/odcs-4257/compose/AppStream/x86_64/os/

2.Try to install skopeo
dnf install skopeo

Actual Results:  
 Problem: conflicting requests
  - nothing provides containers-common >= 4:1-21 needed by skopeo-2:1.14.0-1.el10+2.x86_64 from cs10-appstream


Expected Results:  
skopeo would be installed.

Comment 1 Lokesh Mandvekar 2024-01-04 13:37:38 UTC
I really don't wanna revert to manual changelogs, so I'm thinking we either:

1. Bump Version for every commit like we would otherwise have bumped Release
OR
2. Get rid of min version-release in all packages that depend on containers-common

@dwalsh thoughts ?

Comment 2 Daniel Walsh 2024-01-04 18:08:52 UTC
I would be fine with bumping for each commit.

Comment 3 Lokesh Mandvekar 2024-01-05 10:24:38 UTC
Thanks Dan.

Thinking about this some more, bumping the version for every commit could end up making containers-common dependency hard to manage in dependent packages like podman and skopeo across different Fedora releases and CentOS Streams.

Given that most config files installed by containers-common are sourced from c/common, using c/common's upstream version for the rpm should make Version easier to manage.
The rpm version can then be automatically bumped via packit whenever there's a new c/common upstream release.

Any other changes can then be manually handled without any version bump. For example, updating shortnames.conf, storage.conf, policy.json etc. There shouldn't be as many installation issues with those.

Since upstream c/common is on 0.57.1, I will bump rawhide from "4:1" to "5:0.57.1" to unblock c10s. After that, I'll add a packit job upstream to bump rpm on every release.

Comment 4 Lokesh Mandvekar 2024-01-05 11:07:15 UTC
5:0.57.1-1 building at https://koji.fedoraproject.org/koji/buildinfo?buildID=2341227 . IIUC, c10s should sync automatically from rawhide. Troy, let me know if this unblocks c10s.

Comment 5 Troy Dawson 2024-01-05 21:23:33 UTC
Yes, this built and unblocked c10s.
Thank you very much.


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