On Mon, Jan 29, 2024 at 6:37 AM Neal Gompa <ngomp...@gmail.com> wrote:
> 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. > I agree with Neal, this looks good to me. Thank you for the nice explanation/write-up. Troy
-- _______________________________________________ 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
