RPM packages built in OBS have an unexpected revision format

[xmudrii]

RPM packages built in OBS have a revision format such as <version>-<number>.<x>.<y>. <x>.<y> part is expected and present for Debian packages as well, see this thread for more details: https://kubernetes.slack.com/archives/C03U7N0VCGK/p1692093586272139?thread_ts=1691738497.514679&cid=C03U7N0VCGK

The <number> part is unexpected and only present for RPM packages. This part is coming from SLE (SUSE Linux Enterprise) and represents the SLE version used for building the package: https://kubernetes.slack.com/archives/C03U7N0VCGK/p1692787918872219?thread_ts=1692787743.934119&cid=C03U7N0VCGK

This is how revisions look like for the kubeadm package (note 150500 in revision):

[root@80a754535bb6 /]# yum --showduplicates list kubeadm --disableexcludes=kubernetes
Last metadata expiration check: 0:00:20 ago on Wed Aug 23 10:48:09 2023.
Available Packages
kubeadm.aarch64                                         1.28.0-150500.1.1                                          kubernetes
kubeadm.ppc64le                                         1.28.0-150500.1.1                                          kubernetes
kubeadm.s390x                                           1.28.0-150500.1.1                                          kubernetes
kubeadm.src                                             1.28.0-150500.1.1                                          kubernetes
kubeadm.x86_64                                          1.28.0-150500.1.1                                          kubernetes

We should consider the following:

• Should we drop the <number> part from the revision for RPM packages?
• Should we try to enforce the revision as it is defined in the spec file and not autogenerated by OBS? (this would also affect deb packages)
• If we decide to change the revision, we should consider what effects that might have on existing packages. We should also consider if we want to do it for existing package/OBS repositories or only for new repositories (e.g. for v1.29 and onwards)

cc @kubernetes/release-engineering for input on this

/priority important-soon

[xmudrii]

Important note about this is that we don't provide any guarantees regarding revision for packages in the OBS repos. From https://kubernetes.io/blog/2023/08/15/pkgs-k8s-io-introduction/

• The revision part of the package version (the -00 part in 1.28.0-00) is now autogenerated by the OpenBuildService platform and has a different format. The revision is now in the format of -x.y, e.g. 1.28.0-1.1

[saschagrunert]

• Should we drop the <number> part from the revision for RPM packages?

Yes, that does not provide any beneficial information to the end user.

• Should we try to enforce the revision as it is defined in the spec file and not autogenerated by OBS? (this would also affect deb packages)

I'm wondering why we should do that? In which cases would OBS rebuild the packages and therefore bump the rev?

Edit: Now I see #3220, so we may resolve that point within that issue.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[xmudrii]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[xmudrii]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[xmudrii]

/remove-lifecycle stale