@chantra noticed that a number of our RPMs still have the old "CentOS" vendor. In https://pagure.io/centos-infra/issue/621 we switched our vendor in CBS to be "CentOS Hyperscale SIG", but never actually rebuilt all packages. The result is that if use is using allow_vendor_change=False it's fairly easy to end up in a bad situation on an upgrade. To resolve this we need to bump and rebuild all RPMs that still carry the old vendor (or untag them if they're no longer relevant).
allow_vendor_change=False
Using
$ find . -name \*.rpm | xargs rpm --nosignature -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH};%{SOURCERPM};%{VENDOR}\n' -p
in a full mirror to check this, here's the result: https://docs.google.com/spreadsheets/d/1OHwwAI0bIfK4E0M2tCNJCk9BtHj_Kze5G_9JORo42gU/edit?usp=sharing
I suppose we should only care about the latest package for each repos right? For example, we have multiple version of createrepo_c, and the most recent ones have the right vendor, so they don=E2=80=99t need to be updated= . If none had the right vendor, we would only bump the release of the latest one and rebuild that one. Right?
Yep, though at some point we should consider untagging the older versions with the wrong vendor too.
Metadata Update from @dcavalca: - Issue assigned to salimma
Doing this from a local c9s-hyperscale install with repoquery, since that seems easier than having to mirror everything first:
note: because of https://pagure.io/centos-sig-hyperscale/sig/issue/136 I have to edit the repo definitions so source repos use baseurl instead of metalink, since the metalink URLs all 404ed.
❯ sudo dnf --disablerepo=\* --enablerepo=centos-hyperscale-source,centos-hyperscale-experimental-source repoquery --qf "%{name} %{version} %{vendor}" Last metadata expiration check: 0:07:07 ago on Wed 23 Nov 2022 03:40:18 PM CST. btrfs-progs 5.14.2 CentOS btrfs-progs 5.16.2 CentOS Hyperscale SIG compsize 1.5 CentOS Hyperscale SIG createrepo_c 0.17.7 CentOS Hyperscale SIG createrepo_c 0.20.1 CentOS Hyperscale SIG dmidecode 3.4 CentOS Hyperscale SIG dnf-plugin-cow 0.0.3 CentOS Hyperscale SIG ethtool 5.16 CentOS Hyperscale SIG fio 3.31 CentOS Hyperscale SIG fio 3.32 CentOS Hyperscale SIG fish 3.5.1 CentOS Hyperscale SIG iperf3 3.11 CentOS Hyperscale SIG kernel 5.14.0 CentOS Hyperscale SIG kpatch 0.9.4 CentOS kpatch 0.9.7 CentOS Hyperscale SIG librepo 1.14.2 CentOS Hyperscale SIG librepo 1.14.5 CentOS Hyperscale SIG linuxptp 3.1.1^20220726git6c42e5 CentOS Hyperscale SIG meson 0.61.3 CentOS Hyperscale SIG rpm 4.16.1.3 CentOS Hyperscale SIG snapper 0.10.1 CentOS Hyperscale SIG systemd 249.4 CentOS systemd 250.3 CentOS Hyperscale SIG zsh 5.9 CentOS Hyperscale SIG
No source repos for c8s hyperscale, but heh, you can repoquery the binary repos and ask to output the source package name, then sort and dedup
sudo dnf --disablerepo=\* --enablerepo=centos-hyperscale,centos-hyperscale-experimental repoquery --qf "%{source_name},%{version}-%{release},%{vendor}" | sort | uniq
<img alt="c8s-hs-vendors.csv" src="/centos-sig-hyperscale/sig/issue/raw/files/a63eeb1e5afc4968a001fd1a2feea0138baa791c9e0fa8585f1f91b4e850c809-c8s-hs-vendors.csv" />
Will start untagging the old versions next week after the Thanksgiving break
c9s should be clean now, c8s should be clean for packages where the latest package is already tagged correctly (but there are some that needs to be rebuilt).
One weird thing is that there old kpatch-dnf binary RPMs that supposedly come from kpatch, but I can't find these old 0.2.x versions to untag
http://mirror.facebook.net/centos/8-stream/hyperscale/x86_64/packages-main/Packages/k/
This is finally done, using the new audit tool to drive the cleanup:
In [72]: for k in mapping.TAG_TO_DISTRO.keys(): ...: if 'release' in k: ...: audit.audit(k) ...:
Metadata Update from @salimma: - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.