(In reply to comment #0)
> It seems that gnome-boxes needs /usr/bin/dbus-launch to work

Can you give more details about the problem you've had which makes you think it needs a dbus-launch dep?

I get this error message when I try to start the program:

(gnome-boxes:9025): Boxes-CRITICAL **: media-manager.vala:27: Error connecting to Tracker: Failed to execute child process "dbus-launch" (No such file or directory)

What sort of a session are you running it under?

(In reply to comment #4)
> What sort of a session are you running it under?

It's just an X session, without a desktop environment.

glib2 has some code in gio/gdbusaddress.c which tries to run dbus-launch, but no dbus-x11 dependency. I couldn't find any occurrences of dbus-launch in gnome-boxes and tracker sources, so I'll assume Boxes is triggering this dbus-launch code.

I get this same error

   Failed to execute child process "dbus-launch"

when running eekboard on a very basic X session (also without desktop environment).  So glib2 sounds about right.

I also get it from gnome-terminal, a gtk3 app (but perhaps that's still glib2).

Sorry, I should've noted on F20.

Okay, let's move this to F20, then.

*** Bug 977439 has been marked as a duplicate of this bug. ***

This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. 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 '20'.

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

Still unaddressed in F22.

Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 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.

On rawhide:

1) gnome-terminal now pulls in dbus-x11, not via glib2
2) eekboard still fails (does not pull in dbus-x11)
3) gnome-boxes: untested, but no dbus-x11 appears in the dep list.

I'll reopen against rawhide.

This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle.
Changing version to '25'.

Sorry, but adding /usr/bin/dbus-launch as a dependency in glib is a no go. There are lots of low level programs that link with glib and this would force an X11 dependency on all of them.

I went ahead and reverted this. The dbus dependency needs to be added in apps that use the functionality instead, e.g. gnome-terminal and eekboard and gnome-boxes.

We talk about /usr/lib64/libgio-2.0.so.0. This is the only file that contains dbus-lunch strings. What about moving this library into a separate subpackage and add the dbus-x11 dependency to it.

I actually reported another bug proposing splitting the glib2 libraries because of dependency bloat. I think glib2 is just to big and should be split.

(In reply to Petr Pisar from comment #17)
> We talk about /usr/lib64/libgio-2.0.so.0. This is the only file that
> contains dbus-lunch strings. What about moving this library into a separate
> subpackage and add the dbus-x11 dependency to it.

+1

> I actually reported another bug proposing splitting the glib2 libraries
> because of dependency bloat. I think glib2 is just to big and should be
> split.

+1

The Base Runtime team will definitely want you guys to split glib2-devel so you can use the header files without pulling in perl and python (at least).  That's just an informal heads-up; there's no report for that yet, afaik :)

Ok, I filed bug #1428502 and bug #1428503 to get the dependency added to eekboard and gnome-boxes directly.

Oops I didn't read Petr's comment carefully; that sounds fine too.  Anyway, at least there are bugs tracking what will need to depend on the new subpackage.

(In reply to Colin Macdonald from comment #20)
> Anyway, at least there are bugs tracking what will need to depend on the new
> subpackage.

You won't need because the dependency will be autogenerated via library soname.

Sure, I think splitting gio into a subpackage should be easily doable if needed.

I don't think it would make sense to add a dbus-x11 hard dep to the new gio subpackage though. Most of the code that uses gio works just fine without dbus and adding the dep to the library package would probably just scare off low level consumers from using it in the first place.

E.g. the GTask API from gio is something that is universally useful to help deal with threads. If we add a heavy dep to gio, then suddenly low level consumers such as libdnf would be forced to avoid using the GTask API.