On Mon, Jan 29, 2024 at 2:32 PM David Trudgian via epel-devel <epel-devel(a)lists.fedoraproject.org&gt; wrote: > > Dear all, > > 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. > This seems reasonable to me.

Dear all, 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. Many Thanks, Dave Trudgian [1] https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproj... -- _______________________________________________ epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproj... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue