On Fri, Jan 26, 2024 at 9:39 AM David Trudgian via epel-devel <[email protected]> wrote: > > Thanks for your comments. > > >> I’ve had some discussion with Jonathan Wright elsewhere about the topic of > >> this message, but wanted to verify my understanding is correct before I > >> embark on it, and thought I’d do so on list. > >> > >> singularity-ce is currently packaged at v4.0.3 in Fedora Rawhide, and > >> v.3.11.5 elsewhere (Fedora releases and EPEL). > >> > >> We want to make a v4 available to EPEL users, as many would be interested > >> in it, but I wouldn’t consider it a compatible update because there are > >> some CLI changes, and small behaviour changes. > >> > >> My understanding is that in order to provide a 4.x in EPEL, without any > >> incompatible update happening for users: > >> > >> 1) I create a new package, singularity-ce4, to package the 4.x version. In > >> rawhide, this will be the same as the singularity-ce package currently in > >> rawhide, but needs new package review etc. > > > > Creating a versioned package does NOT require a new review[1], though > > if you feel that packaging changes are going to be large enough to > > warrant one, you may still request it. > > The linked document mentions - "The package MUST be properly named according > to the naming guidelines and MUST NOT conflict with all other versions of the > same package.” > > (https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process) > > I read this as both versions should be installable at the same time? This is > not easily the case here, as singularity has to provide a `run-singularity` > executable that may called from a '#!/usr/bin/env run-singularity’ embedded > in our container image format. > > It’s also perhaps complicated by the fact that we already conflict with the > apptainer package that provides /usr/bin/[run-]singularity and attempts to > migrate configuration. We both have a ‘Provides/Conflicts: sif-runtime’, and > `Provides: alternative-for(singularity)` around this. I’d assume preserving > the right behaviour there deserves review. This is all complication arising > from singularity-ce and apptainer being separate forks of the project > previously known as ’singularity’. > > >> 2) For rawhide / upcoming f40 *only*, the new singularity-ce4 package will > >> provide/obsolete singularity-ce as it is the same thing … and > >> singularity-ce can be retired in rawhide. > > > >> 3) When singularity-ce4 is added to EPEL it will *not* provide/obsolete > >> singularity-ce, but a message can be added to %post to inform people about > >> the availability of v4. > > > > Do not do this. %post messages are really only intended to inform > > users of failures and, frankly, no one reads them until something has > > gone wrong. Even then, it's only going to be the sysop for the machine > > that sees it, who may not be the person who deals with Singularity. > > Agreed. This was a prior suggestion made to me. > > > > > I don't know anything about Singularity, but if it has a user > > interface of any kind (like the CLI), what you might want to do is add > > a wrapper around it that prints your message. That's much more likely > > to be viewed by the people who would care. > > We can certainly do that. > > > > >> At some point in the future, if 3.x is no longer maintainable for good > >> reason, then the incompatible update procedure can be pursued to make > >> singularity-ce4 provide/obsolete singularity-ce in EPEL 7/8/9 - and > >> singularity-ce is fully retired. EPEL 10 will only get singularity-ce4. > > > > Is v3 still supported upstream today? If not, you probably want to > > make the message above a deprecation notice and add an EOL date. > > v3 is only minimally supported upstream, and entirely for the purposes of > having it in Fedora & EPEL without forcing an incompatible upgrade. It’s > unsupported in any other form (outside of commercial LTS). I am both the > upstream maintainer and the packager here, both in the context of employment. > It would be beneficial if I didn’t need to spend any time on maintaining v3 > at all, but we are attempting to meet the broad expectations of EPEL, given > we are both upstream and packaging... > > Since I am both the upstream maintainer, and the downstream packager of > singularity-ce, it seems somewhat hard to argue I can’t keep it updated for > at least a while with backports to avoid forcing an incompatible update. I do > the bundled dependency updates etc. upstream, rather than via packaging > patches or similar, for my own convenience. > > In previous discussions with others involved in EPEL it seemed that it was > perhaps considered reasonable to try and maintain the v3 in EPEL until such > time as it drops out of a stable Fedora, or there is a security issue with a > fix that is not reasonably practical to back port.
Well, EPEL 7 is EOL in five months, so it may not be worth it to spend this effort there. For singularity-ce in EPEL 8 and EPEL 9, you can do an incompatible upgrade and give notice, per the policy[1]. Lack of upstream maintenance of singularity v3 is sufficient grounds for this, because we do not expect volunteers to do crazy backport work. [1]: https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/ -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ epel-devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
