Per the incompatible upgrade policy, I posted a message on the epel-devel list on Monday 29th January, seeking permission for an incompatible update of singularity-ce:

https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/PTZQ2TJDN753BUQ7R7UY3JNTC5WDF2RE/

From the policy, I understand that:

Discussion takes place on epel-devel for a minimum period of 1 week.

Item is added to agenda for discussion at weekly EPEL meeting.

(https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/#process_for_incompatible_upgrades)

I believe that EPEL meeting items are taken from this issue tracker, so as the post to the epel-devel list was more than a week ago, I'm creating this issue to request that it is discussed at the meeting.

Original message posted to epel-devel on Monday 29th January is below, for reference:

Following advice from Neal elsewhere on this list [1], I’m requesting that the
singularity-ce EPEL packages may be updated to 4.1.0 following the incompatible upgrade
procedure. The justification for the upgrade is that 3.x singularity-ce is no longer
maintained upstream. Note that because singularity-ce necessarily bundles many Go
dependencies specified in upstream go.mod/go.sum, lack of maintenance can quickly lead to
inherited security issues.

Upstream singularity-ce (https://github.com/sylabs/singularity) maintenance is limited to
the latest x.y minor version, currently 4.1. The upstream project has committed more
formally to semantic versioning conventions since 4.0.0, so any 4.y.z minor (y) and patch
(z) version updates are expected to be compatible upgrades for EPEL purposes.

At present, singularity-ce in EPEL 7/8/9 has been held at 3.11.5 due to incompatible
changes.

Incompatibilities from 3.11.5 -> 4.1.0 are as follows:

(a) The CLI has split some functionality previously provided by the singularity remote
command into new singularity registry and singularity keyserver commands.
(b) The singularity remote add command now sets a newly added remote as the default
(unless suppressed). Previously the user had to set the default remote manually.
(c) The —vm flag to start singularity inside a Virtual Machine has been removed. This
was not intended to be user facing, but was used by a separate and proprietary Singularity
Desktop project that has been retired for some time. —vm was unmaintained, and I don’t
believe there is any practical use outside of this context.

(d) Bind mounts are now performed in the order in which they are specified. Previously,
image based bind mounts were performed before others.
(e) Current working directory on the host is now created in the container, restoring a
behaviour from Singularity <3.6.0 unless suppressed.
(f) If the current directory paths on the container and host contains symlinks to
different locations, the current working directory is not mounted.

The above are expected to have a minor impact on users. Arguably (d)/(e)/(f) are bug fixes
as they address issues reported by users as unexpected behaviour. Changes (e)/(f) were
also previously included in the apptainer project's upgrade to their v1.2.0 that was
not submitted as an incompatible upgrade.

Highlighting also for Dave Dykstra’s benefit that any thoughts around the relevance of
incompatible upgrade policy to (b) & (c) will also be relevant to apptainer’s upcoming
1.3.0 upgrade, as apptainer has pulled both of these changes from singularity-ce
upstream.

Other changes in behaviour from 3.11.5 -> 4.1.0 are compatible. Configuration files do
not need to be modified.