https://bugzilla.redhat.com/show_bug.cgi?id=2034758
--- Comment #9 from Mattia Verga mattia.verga@protonmail.com --- (In reply to Dave Dykstra from comment #7)
It's not clear to me what version to include with Provides =, since the apptainer version number has been re-set to 1.0.0. The packaging guidelines say it should usually be a macro that increases with new versions of the newly renamed package, but that would be difficult to do since you can't do math on a version number, for example to add 3.0.0 to whatever the current version is. I guess I will just set it to a constant 4.0.0-1, because that's what the number would have been if it hadn't been reset to 1.0.0.
mmm that's an uncommon situation. In my opinion, you can/should use an Epoch bump like:
Provides: singularity = 1:%{version}-%{release} Obsoletes: singularity <= 3.8.5-4
From the packaging guidelines:
If a package is being renamed without any functional changes, or is a compatible enough replacement to an existing package (where "enough" means that it includes only changes of magnitude that are commonly found in version upgrade changes), provide clean upgrade paths and compatibility with:
Provides: oldpackagename = $provEVR Obsoletes: oldpackagename < $obsEVR
$provEVR refers to an (Epoch-)Version-Release tuple the original unchanged package would have had if it had been version or release bumped.