Bug 1714929 - signon/gsignond conflicts: /usr/share/dbus-1/services/com.google.code.AccountsSSO.SingleSignOn.service
Summary: signon/gsignond conflicts: /usr/share/dbus-1/services/com.google.code.Account...
Alias: None
Product: Fedora
Classification: Fedora
Component: gsignond
Version: 30
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Fabio Valentini
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2019-05-29 08:22 UTC by Gianluca Cecchi
Modified: 2020-05-26 15:30 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2020-05-26 15:30:26 UTC
Type: Bug

Attachments (Terms of Use)

Description Gianluca Cecchi 2019-05-29 08:22:38 UTC
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):

How reproducible:

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:

 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
 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:

 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..

Comment 1 Rex Dieter 2019-05-29 13:18:59 UTC
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

Comment 2 Rex Dieter 2019-05-29 13:20:10 UTC
Looks like these are both subprojects under

I'll see if there are any newer releases that resolve this before reporting bug(s) there

Comment 3 Rex Dieter 2019-05-29 13:24:31 UTC
Seems upstream is (may be?) aware of it, only relevant upstream issue I found so far,

Comment 4 Rex Dieter 2019-05-29 13:31:37 UTC
triaging to gsignond for real this time.

Comment 5 Fabio Valentini 2019-05-29 13:45:06 UTC
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.

Comment 6 Rex Dieter 2019-05-29 13:48:05 UTC
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.

Comment 7 Fabio Valentini 2019-05-29 14:44:02 UTC
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

Comment 8 Ben Cotton 2020-04-30 21:53:47 UTC
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.

Comment 9 Ben Cotton 2020-05-26 15:30:26 UTC
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

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.