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. -- _______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
