Bug 2158332

I can see that an obsoletes was added to apptainer-1.1.4-3 [0].  This is probably not the best fix, and doesn't line up with the recommendation given by the EPEL steering committee [1].  Please revert it.  Instead, you can just add a conflicts to apptainer.  That will prevent the long error message, and instead just inform users that apptainer and singularity can't be installed at the same time.  The correct thing still happens when users run `yum update` (apptainer-suid and apptainer are installed, singularity is removed).

apptainer:
Conflicts: singularity < 3.8.7-4

apptainer-suid:
Obsoletes: singularity < 3.8.7-4


[0] https://src.fedoraproject.org/rpms/apptainer/c/9a95af1ffb7ece3b1ae2ef1cb2ae70ea370f5052?branch=rawhide
[1] https://pagure.io/epel/issue/215

That is another possibility I had thought of and it's probably what I'll do, but first please explain why having a Conflicts is better than Obsoletes.  The second Obsoletes still has the same effect with a `yum update`, and it is more convenient for the users.

The effect is only the same with dnf (or the yum symlink to dnf).  Having two packages obsolete one package doesn't work the same in actual yum in EL7.  In your given scenario (having singularity installed and trying to install apptainer before running `yum update`), it results in only apptainer being installed, not apptainer-suid.  apptainer-suid isn't pulled in by future updates either.  Based on this and the discussions about apptainer compatibility, the correct action is to only have apptainer-suid have the obsoletes, and to add just a conflicts to apptainer.

> In your given scenario (having singularity installed and trying to install apptainer before running `yum update`), it results in only apptainer being installed, not apptainer-suid. 

But that's exactly what users expect if they are explicitly asking for apptainer.  If they are asking for that package, they obviously are aware of the name change, and they will expect it to replace the singularity rpm and to be non-suid by default because that's what apptainer is.  If on the other hand they do `yum update singularity` they will still get both packages, even with yum on EL7.  So it seems to me to be exactly the expected and correct behavior.

If I haven't convinced you and don't hear any different from other EPEL Steering Committee members, I will go ahead and do what you ask but submit a second request to FESCo to change it from Conflicts to Obsoletes, in addition to the request I plan to submit for adding "Provides: singularity" to apptainer-suid.  I really believe that both are best for the users and are what users expect.

I'm expecting an apptainer 1.1.5 release early next week, so I think the packaging change will be made along with that release.

Oh, but as you alluded too, the dnf behavior with the second Obsoletes is different, to install both packages.  I think that is unexpected behavior.  So maybe the Conflicts is better after all, so people can get only the package they ask for after removing singularity.

> But that's exactly what users expect if they are explicitly asking for apptainer.  If they are asking for that package, they obviously are aware of the name change, and they will expect it to replace the singularity rpm and to be non-suid by default because that's what apptainer is.

I'm not sure that's always true.  And even when it is, using a conflicts is still better so we're not assuming user intent.  With just a conflicts, no obsoletes, it would look like this:

- have singularity installed
- `yum install apptainer`
- see that apptainer conflicts with the installed singularity
- uninstall singularity and then install apptainer, either separately or in the same transaction (`yum swap` or `yum shell`)

That is a perfectly fine workflow that makes no assumptions.  There really is no significant benefit to having the obsoletes on apptainer also.  The recommended path is available via `yum update`.  Between that and the difference in behavior between dnf and yum, just sticking with the conflicts is best.

Ok I was convinced to do it, but I tried putting in a "Conflicts: singularity <= 3.8.7-3" on the apptainer package and I don't see the behavior you were expecting.  On both EL7 and EL8, a `yum install apptainer` while singularity is installed surpringly installs both apptainer and apptainer-suid.  On EL7 it gives these details:

--> Running transaction check
---> Package apptainer.x86_64 0:1.1.4~0.0.20230105170603.dwd.305.g8d1a657git-1.el7 will be installed
--> Processing Conflict: apptainer-1.1.4~0.0.20230105170603.dwd.305.g8d1a657git-1.el7.x86_64 conflicts singularity <= 3.8.7-3
--> Restarting Dependency Resolution with new changes.
--> Running transaction check
---> Package apptainer-suid.x86_64 0:1.1.4~0.0.20230105170603.dwd.305.g8d1a657git-1.el7 will be obsoleting
---> Package singularity.x86_64 0:3.8.7-1 will be obsoleted
--> Finished Dependency Resolution

So I don't know if there is a way to make it do anything else (other than on EL7 an Obsoletes will install only apptainer).

(I wish that bugzilla had an edit feature.  surpringly -> surprisingly)

Ah, that's good that yum is actually smart enough to see a resolution path (installing apptainer-suid to obsolete singularity in the same transaction).  That's the end goal anyways and the same thing that would happen if a users runs `yum update`.

I think it would surprise users, but it's at least consistent and I don't know anything better, so is in the 1.1.5 version that was just released

https://github.com/apptainer/apptainer/pull/990

FEDORA-2023-0be2c66af0 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2023-0be2c66af0

FEDORA-EPEL-2023-253bcc4444 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-253bcc4444

FEDORA-2023-d139c5b447 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-d139c5b447

FEDORA-EPEL-2023-0b5a551aaf has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-0b5a551aaf

FEDORA-EPEL-2023-bdb426dc1d has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-bdb426dc1d

FEDORA-EPEL-2023-0b5a551aaf has been pushed to the Fedora EPEL 9 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-0b5a551aaf

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-EPEL-2023-bdb426dc1d has been pushed to the Fedora EPEL 8 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-bdb426dc1d

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-EPEL-2023-253bcc4444 has been pushed to the Fedora EPEL 7 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-253bcc4444

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2023-d139c5b447 has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-d139c5b447`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-d139c5b447

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2023-0be2c66af0 has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-0be2c66af0`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-0be2c66af0

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2023-d139c5b447 has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-EPEL-2023-0b5a551aaf has been pushed to the Fedora EPEL 9 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-EPEL-2023-bdb426dc1d has been pushed to the Fedora EPEL 8 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-EPEL-2023-253bcc4444 has been pushed to the Fedora EPEL 7 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2023-0be2c66af0 has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.