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.fedoraproject...
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.
On Mon, Jan 29, 2024 at 6:37 AM Neal Gompa ngompa13@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
On Mon, Jan 29, 2024 at 06:40:19AM -0800, Troy Dawson wrote:
On Mon, Jan 29, 2024 at 6:37 AM Neal Gompa ngompa13@gmail.com wrote:
This seems reasonable to me.
I agree with Neal, this looks good to me. Thank you for the nice explanation/write-up.
Yeah, same here. Seems reasonable...
kevin
This was approved at the last EPEL Steering Committee meeting. You may go ahead with your plan. Thank you for following the procedure.
On Mon, Jan 29, 2024 at 6:33 AM 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.
Many Thanks,
Dave Trudgian
[1] https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject... -- _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@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... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
epel-devel@lists.fedoraproject.org