#1778 Missing builds from repo after renaming package.
Opened by aleasto. Modified

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.

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.

History of the package:

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.

The status of the repos:

$ 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:

  • We need to include breeze-icon-theme package.
  • There are two candidates: breeze-icon-theme-6.3.0-1.fc40.x86_64 and breeze-icon-theme-6.5.0-1.fc40.noarch.
  • Pungi asks dnf to get the latest one. However, that call runs per name and architecture, so neither of them is latest and both still remain an option.
  • Another heuristic triggers to figure out which one to use, and it picks the older version for whatever reason.

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.

Metadata