https://bugzilla.redhat.com/show_bug.cgi?id=2034758
--- Comment #9 from Mattia Verga <mattia.verga(a)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.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
https://bugzilla.redhat.com/show_bug.cgi?id=2034758