Hi, we've encountered an issue when renaming a source package in Fedora.
The breeze-icon-theme SRPM used to build a bunch of rpms, of which breeze-icon-theme and breeze-icon-theme-rcc. We've redone the package under a different SRPM name kf6-breeze-icons, but keeping some of the same subpackage names, including the two previously mentioned. The assumption here is that when building a higher version, the new RPMs would upgrade the ones being built from the old SRPM, without even needing Obsoletes: migration paths.
breeze-icon-theme
breeze-icon-theme-rcc
kf6-breeze-icons
Obsoletes:
In F41+ the breeze-icon-theme SRPM is retired, the new kf6-breeze-icons SRPM is building correctly, and all seems good. In F40 we cannot retire the old SRPM mid-cycle but we've started using the new SRPM anyways, still under the assumption that since we're building higher versions package upgrades would work fine.
However we've found out that, despite the kf6-breeze-icons SRPM building correctly and passing the testing phase in bodhi, the breeze-icon-theme-rcc RPM does not end up in the f40-updates repo. On the contrary, the breeze-icon-theme RPM is picked up just fine. Both RPMs are built from the same SRPM, yet one of the two is missing.
We thought the issue might have something to do with the package temporarily switching from noarch to archful in the old SRPM, then back to noarch in the new SRPM. We added explicit Obsoletes: statements following an old thread that suggested than when changing architecture like this one should add explicit upgrade paths with Obsoletes; however this did not make a difference. Indeed both breeze-icon-theme and breeze-icon-theme-rcc went through the same noarch changes, but only breeze-icon-theme-rcc is missing from the repos.
F40 stable shipped the breeze-icon-theme SRPM at version 6.0.0-1. The package was updated normally to 6.2.0-1. The package then changed to being archful in 6.3.0-1. This was the last version built from this SRPM. After that, we started using the new kf6-breeze-icons SRPM building the same subpackages as noarch again, with version 6.3.0-2 The new SRPM was updated with versions 6.4.0-1, 6.5.0-1 and 6.5.0-2, the latest being where we tried adding Obsoletes statements.
$ dnf4 repoquery breeze-icon-theme --qf="%{REPONAME}\t %{NAME}-%{EVR}.%{ARCH}" fedora breeze-icon-theme-6.0.0-1.fc40.noarch updates breeze-icon-theme-6.3.0-1.fc40.i686 updates breeze-icon-theme-6.3.0-1.fc40.x86_64 updates breeze-icon-theme-6.5.0-2.fc40.noarch
Odd, the latest noarch build is not overwriting the previous archful builds. But at least the latest build is there.
$ dnf4 repoquery breeze-icon-theme-rcc --qf="%{REPONAME}\t%{NAME}-%{EVR}.%{ARCH}" fedora breeze-icon-theme-rcc-6.0.0-1.fc40.noarch updates breeze-icon-theme-rcc-6.3.0-1.fc40.x86_64
All builds from the new SRPM are missing. An i686 build is also missing compared to breeze-icon-theme.
@kevin suggested this might be an issue with pungi, or actually just a consequence of pungi ordinarily works. Still this is creating dependency issues, and it remains to be explained why one subpackage is picked up correctly while the other one is not.
Can you help us figure this out?
Thanks, Alessandro, Fedora KDE-SIG.
Something like this is happening:
breeze-icon-theme-6.3.0-1.fc40.x86_64
breeze-icon-theme-6.5.0-1.fc40.noarch
This is possibly a bug, though I'm not sure fixing just this specific issue will help here. There may be other issues affecting this case.
@lsedlar
What do you suggest we do here? I have no idea how to debug pungi.
The f40 updates repo has broken dependencies because of this issue.
This issue has been migrated to Fedora Forge: https://forge.fedoraproject.org/pungi/pungi/issues/1778
Please continue any further discussion there.