On Mon, Jan 29, 2024 at 2:32 PM David Trudgian via epel-devel <epel-devel@lists.fedoraproject.org> 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. -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
