[EPEL-devel] Re: Incompatible Upgrade Request - singularity-ce
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.org/message/IQENLTYUAIMOTAX4LUWHYINOPSCRWCIS/ > -- > ___ > 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 > -- ___ 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
[EPEL-devel] Re: Incompatible Upgrade Request - singularity-ce
On Mon, Jan 29, 2024 at 06:40:19AM -0800, Troy Dawson wrote: > On Mon, Jan 29, 2024 at 6:37 AM Neal Gompa 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 signature.asc Description: PGP signature -- ___ 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
[EPEL-devel] Re: Incompatible Upgrade Request - singularity-ce
On Mon, Jan 29, 2024 at 6:37 AM Neal Gompa wrote: > On Mon, Jan 29, 2024 at 2:32 PM David Trudgian via epel-devel > 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
[EPEL-devel] Re: Incompatible Upgrade Request - singularity-ce
On Mon, Jan 29, 2024 at 2:32 PM David Trudgian via epel-devel 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