The systemd wiki page (http://wiki.gentoo.org/wiki/Systemd) mentions the systemd use flag. After enabling this flag globally (in make.conf), and then trying to update my system, I find out there is a circular dependency between systemd and dbus-1.6.8-r1. Obviously, this is fixed by removing the systemd use flag for dbus, but I doubt this is a safe choice. Reproducible: Always Steps to Reproduce: Enable the 'systemd' use flag for =sys-apps/dbus-1.6.8-r1, then try emerging it. Actual Results: I'm unable to update my system to get systemd running. Expected Results: Updating my system works.
(In reply to comment #0) > The systemd wiki page (http://wiki.gentoo.org/wiki/Systemd) mentions the > systemd use flag. After enabling this flag globally (in make.conf), and then > trying to update my system, I find out there is a circular dependency > between systemd and dbus-1.6.8-r1. > Obviously, this is fixed by removing the systemd use flag for dbus, but I > doubt this is a safe choice. Yes, it is generally safe. In this case, USE=systemd means logind access checking support. I'd rather enable it back after merging systemd but that's something completely acceptable for the transition.
I have updated the Wiki to recommend installing systemd before enabling the flag which should fix the issue. Is there anything else we can do here?
The HAVE_SYSTEMD the --enable/--disable controls bus/Makefile.am to generate some files from *.in files So at least in theory those could be moved to own package, like dbus-systemd and drop the USE flag from dbus At least for me this is a NeedPatch case ;-)
(In reply to comment #3) > The HAVE_SYSTEMD the --enable/--disable controls bus/Makefile.am to generate > some files from *.in files > So at least in theory those could be moved to own package, like dbus-systemd > and drop the USE flag from dbus > At least for me this is a NeedPatch case ;-) dbus/dbus-userdb-util.c:#if HAVE_SYSTEMD dbus/dbus-userdb-util.c:#ifdef HAVE_SYSTEMD It seems to be used commonly by a number of D-Bus binaries. I'd say that a solution would be to split D-Bus into libdbus and dbus-daemon. Then systemd would DEP on libdbus and RDEP on dbus-daemon[systemd], and portage would be able to merge it without circular deps.
Oh, I have re-checked D-Bus sources and it seems that they really suck at design. 1) --enable-systemd affects HAVE_SYSTEMD in config.h, so only the logind feature in sources, 2) --with-systemd-systemunitdir (always on) affects HAVE_SYSTEMD in Makefiles, so the install of unit files. So, dbus[systemd] is not mandatory for systemd to run.
Looks like libdbus and dbus-daemon could be splitted, but that would require some work :S
This is a trivial circular dependency with an obvious solution (emerge dbus with USE=-systemd; emerge systemd; emerge dbus with USE=systemd). Can't we fix portage to handle these kinds of circular dependencies properly?
I am sure I talked about this with Zac months ago and it wasn't so easy... but maybe now that there are more people in portage team would become "easier" :/ https://bugs.gentoo.org/show_bug.cgi?id=479986#c14 and newer comments/suggestions (finally found the bug report ;))
(In reply to Pacho Ramos from comment #8) > I am sure I talked about this with Zac months ago and it wasn't so easy... > but maybe now that there are more people in portage team would become > "easier" :/ We just had a discussion on IRC and it turned that there are several problems here: a) Even if portage would automatically find a solution, it wold not be clear to the user if applying the solution is safe. b) There were some proposals to add information about the circular dependency to the ebuilds. Either with a DEPEND like syntax for the PM to use or as annotation with human readable hints for the user. This leads to the problem that these hints need to be safe and may have to be updated in case they become unsafe at some point. But they may still be better than the current situation. Automatically applying a solution for the circular dependency (where ever it comes from) seems out of reach for now. The DEPEND like syntax doesn't seem to be worth it right now to me, as emerge couldn't make real use of it. If someone wants to pursue the route of annotations, feel free. They maybe useful in other situations too.
(In reply to Matt Turner from comment #7) > This is a trivial circular dependency with an obvious solution (emerge dbus > with USE=-systemd; emerge systemd; emerge dbus with USE=systemd). Can't we > fix portage to handle these kinds of circular dependencies properly? good point, however for this particular bug I think we are waiting for systemd to migrate more to kernel's kdbus and drop it's sys-apps/dbus dependency unless the plans have changed again
(In reply to Samuli Suominen from comment #10) > (In reply to Matt Turner from comment #7) > > This is a trivial circular dependency with an obvious solution (emerge dbus > > with USE=-systemd; emerge systemd; emerge dbus with USE=systemd). Can't we > > fix portage to handle these kinds of circular dependencies properly? > > good point, however for this particular bug I think we are waiting for > systemd to migrate more to kernel's kdbus and drop it's sys-apps/dbus > dependency > unless the plans have changed again I believe the plan is to use kdbus if possible, but can and will still use sys-apps/dbus (which will be required for anything that doesn't use the zomglatestkernels - so anything not x86/amd64 :( )
systemd no longer needs dbus at build time.
