Thanks for your comments.
> I’ve had some discussion with Jonathan Wright elsewhere about the
topic of this message, but wanted to verify my understanding is correct before I embark on
it, and thought I’d do so on list.
>
> singularity-ce is currently packaged at v4.0.3 in Fedora Rawhide, and v.3.11.5
elsewhere (Fedora releases and EPEL).
>
> We want to make a v4 available to EPEL users, as many would be interested in it, but
I wouldn’t consider it a compatible update because there are some CLI changes, and small
behaviour changes.
>
> My understanding is that in order to provide a 4.x in EPEL, without any incompatible
update happening for users:
>
> 1) I create a new package, singularity-ce4, to package the 4.x version. In rawhide,
this will be the same as the singularity-ce package currently in rawhide, but needs new
package review etc.
Creating a versioned package does NOT require a new review[1], though
if you feel that packaging changes are going to be large enough to
warrant one, you may still request it.
The linked document mentions - "The package MUST be properly named according to the
naming guidelines and MUST NOT conflict with all other versions of the same package.”
(
https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuideline...)
I read this as both versions should be installable at the same time? This is not easily
the case here, as singularity has to provide a `run-singularity` executable that may
called from a '#!/usr/bin/env run-singularity’ embedded in our container image
format.
It’s also perhaps complicated by the fact that we already conflict with the apptainer
package that provides /usr/bin/[run-]singularity and attempts to migrate configuration. We
both have a ‘Provides/Conflicts: sif-runtime’, and `Provides:
alternative-for(singularity)` around this. I’d assume preserving the right behaviour there
deserves review. This is all complication arising from singularity-ce and apptainer being
separate forks of the project previously known as ’singularity’.
> 2) For rawhide / upcoming f40 *only*, the new singularity-ce4
package will provide/obsolete singularity-ce as it is the same thing … and singularity-ce
can be retired in rawhide.
> 3) When singularity-ce4 is added to EPEL it will *not* provide/obsolete
singularity-ce, but a message can be added to %post to inform people about the
availability of v4.
Do not do this. %post messages are really only intended to inform
users of failures and, frankly, no one reads them until something has
gone wrong. Even then, it's only going to be the sysop for the machine
that sees it, who may not be the person who deals with Singularity.
Agreed. This was a prior suggestion made to me.
I don't know anything about Singularity, but if it has a user
interface of any kind (like the CLI), what you might want to do is add
a wrapper around it that prints your message. That's much more likely
to be viewed by the people who would care.
We can certainly do that.
> At some point in the future, if 3.x is no longer maintainable for good reason, then
the incompatible update procedure can be pursued to make singularity-ce4 provide/obsolete
singularity-ce in EPEL 7/8/9 - and singularity-ce is fully retired. EPEL 10 will only get
singularity-ce4.
Is v3 still supported upstream today? If not, you probably want to
make the message above a deprecation notice and add an EOL date.
v3 is only minimally supported upstream, and entirely for the purposes of having it in
Fedora & EPEL without forcing an incompatible upgrade. It’s unsupported in any other
form (outside of commercial LTS). I am both the upstream maintainer and the packager here,
both in the context of employment. It would be beneficial if I didn’t need to spend any
time on maintaining v3 at all, but we are attempting to meet the broad expectations of
EPEL, given we are both upstream and packaging...
Since I am both the upstream maintainer, and the downstream packager of singularity-ce, it
seems somewhat hard to argue I can’t keep it updated for at least a while with backports
to avoid forcing an incompatible update. I do the bundled dependency updates etc.
upstream, rather than via packaging patches or similar, for my own convenience.
In previous discussions with others involved in EPEL it seemed that it was perhaps
considered reasonable to try and maintain the v3 in EPEL until such time as it drops out
of a stable Fedora, or there is a security issue with a fix that is not reasonably
practical to back port.