Bug 2254254

Summary:	Containers-common should have versions
Product:	[Fedora] Fedora	Reporter:	Troy Dawson <tdawson>
Component:	containers-common	Assignee:	Lokesh Mandvekar <lsm5>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	bbaude, dwalsh, jnovy, lsm5
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2024-01-19 13:12:21 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.