Description of problem: I have gsignond-1.2.0-3.fc30.x86_64 installed. If I try to install okular I get error due to signon and gsignond conflict Version-Release number of selected component (if applicable): 18.12.2-1.fc30 How reproducible: always Steps to Reproduce: 1. have gsignond installed and okular not installed 2. dnf install okular Actual results: Running transaction check Transaction check succeeded. Running transaction test The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'dnf clean packages'. Error: Transaction check error: file /usr/share/dbus-1/services/com.google.code.AccountsSSO.SingleSignOn.service conflicts between attempted installs of gsignond-1.2.0-2.fc30.x86_64 and signon-8.60-2.fc30.x86_64 Expected results: correct install of okular Additional info: This system was a new Fedora 30 install. The "dnf install okular" command gives as output: ... Installing: okular x86_64 18.12.2-1.fc30 fedora 4.0 M Installing dependencies: ... signon x86_64 8.60-2.fc30 fedora 395 k signon-plugin-oauth2 x86_64 0.22-9.fc30 fedora 78 k ... Installing weak dependencies: ghostscript-core x86_64 9.26-4.fc30 fedora 12 k qca-qt5-ossl x86_64 2.2.0-0.10.20181017.fc30 fedora 105 k qt5-qtspeech-speechd x86_64 5.12.1-1.fc30 fedora 25 k Downgrading: gsignond x86_64 1.2.0-2.fc30 fedora 84 k ... and then fails with the error described above. If I try "dnf remove gsignond" I get: Removing: gsignond x86_64 1.2.0-3.fc30 @updates 334 k Removing dependent packages: switchboard-plug-onlineaccounts x86_64 2.0.1-2.fc30 @fedora 659 k Removing unused dependencies: gsignond-default-config noarch 1.2.0-3.fc30 @updates 794 gsignond-libs x86_64 1.2.0-3.fc30 @updates 386 k gsignond-plugin-lastfm x86_64 0-0.2.20180507.git0a7a5f8.fc30 @fedora 51 k gsignond-plugin-mail x86_64 0.3.0-2.fc30 @fedora 51 k gsignond-plugin-oauth x86_64 0-0.6.20180513.git43fee49.fc30 @fedora 92 k gsignond-plugin-sasl x86_64 0-0.6.20171111.git671022f.fc30 @fedora 51 k libaccounts-glib x86_64 1.23-7.fc30 @fedora 256 k libgsasl x86_64 1.8.0-15.fc30 @fedora 602 k libntlm x86_64 1.4-12.fc30 @fedora 143 k signon-glib x86_64 2.1-4.fc30 @fedora 209 k I didn't accept the removal.. I don't know the impact..
signon was around first, so assigning to gsignond. We'll need to coordinate some solution to the signon vs gsignond conflict about both claiming ownership of /usr/share/dbus-1/services/com.google.code.AccountsSSO.SingleSignOn.service
Looks like these are both subprojects under https://gitlab.com/accounts-sso I'll see if there are any newer releases that resolve this before reporting bug(s) there
Seems upstream is (may be?) aware of it, only relevant upstream issue I found so far, https://gitlab.com/accounts-sso/signond/issues/5
triaging to gsignond for real this time.
Ugh. Not this again ... signon and gsignond are *supposed* to conflict with the latest versions, because they provide the same DBus interface and service. I tried adding the necessary RPM metadata (Conflicts) to both gsignond and signon, but if dnf tries to downgrade the packages to a version that don't have the explicit conflict yet, I have no idea how to resolve that.
I'm signon maintainer, I'm was not aware of any efforts to resolve this conflict (yet). (If I was notified, sorry, I clearly forgot). That said, this needs to be resolved somehow. Fedora packaging policy is pretty clear that Conflicts are to be avoided if at all possible.
Yes, I know that Conflicts are a good solution here. IIRC, this is how this situation got the way it is: 1. originally, signond and gsignond were incompatible, but similar daemon implementations backing different SignOn dbus interfaces. 2. upstream decided this was silly, and decided to agree on a shared DBus interface, with both services provide. 3. both packages were already packaged for fedora, and the latest versions now conflicted on the DBus service file. 4. originally, gsignond was part of the Pantheon comps group, where I had to remove it - to fix installing Pantheon on systems where signon was already installed, and should therefore be the preferred SignOn service provider. [1] 5. I had to add explicit Conflicts to fix the broken upgrade path from fedora 29, if gsignond was installed. This issue was only reported to me after the fedora 30 final freeze - I had not encountered it before in my testing. So ... I think the resolution we came up with for the original problem (4. for the installation issue, and then 5. to fix upgrade issues) is likely the cause of the current issue. And now I'm not at all sure what the way forward should be. [1]: https://pagure.io/fedora-comps/pull-request/385
This message is a reminder that Fedora 30 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '30'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 30 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 30 changed to end-of-life (EOL) status on 2020-05-26. Fedora 30 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.