Please provide a Gnome38 profile. The forum is drowning of ever the same issue udev->ystemd consolekit->logind genkernel->dracut Really it isn't fun anymore ... Reproducible: Always
If this isn't possible the speedy way then simply mask Gnome-3.8 again. I wonder why the Gnome maintainers didn't see this coming ...
(In reply to Ulenrich from comment #0) > genkernel->dracut Dracut is not needed; I am running genkernel + systemd + gnome-3.8 without any problems. However, you are right that a profile with USE="systemd -consolekit" and blocking problematic flags on a few specific packages would be useful.
(In reply to Ulenrich from comment #0) > Please provide a Gnome38 profile. > The forum is drowning of ever the same issue > > udev->ystemd > consolekit->logind > genkernel->dracut > > Really it isn't fun anymore ... > > Reproducible: Always We need to get explanation about exact issues: - udev->systemd -> what exact problem? static-libs one? That is bug 478476 -> the problem of that one is that we can mask offending use flag (that could be done in plain "gnome" profile). But we are waiting for people to decide what to do with that issue because static linking is completely broken for them at the moment, and maybe it should be dropped. Be sure we will reach a solution (or workaround) at the time gnome 3.8 is going to be stabilized but, until then, better wait for seeing what is finally decided - consolekit -> logind -> what are you referring here? If you are talking about the blocker, that is a wrong block that is being handled in bug 478258 - genkernel-> dracut -> the same, please explain what exact problem are you suffering. This looks to me more like a documentation problem that a problem that could be fixed with a profile change (In reply to Ulenrich from comment #1) > If this isn't possible the speedy way then simply mask Gnome-3.8 again. > I wonder why the Gnome maintainers didn't see this coming ... Because it's far more easy to see how other should handle it in a "theoretical" point of view than going ahead and trying to fix the situation. For example, with the consolekit blocker I have explained why I think it's completely wrong... but I am waiting for the dev who added that block to see the problem. Regarding the static-libs issue, I was trying to handle the issue in mailing list, pinging developers implicated... As a side note, I am following "Gnome 3.8" forums thread... and this kind of problems were being handled... but could people please stop suggesting users to add multiple hacks to prevent systemd migration? I have seen recommendations like masking gnome-settings-daemon-3.8 (!), that is completely unsupported but I haven't replied to that thread because I am tired of, then, needing to explain again and again why we need systemd and, finally, people getting angry with me because they think *I* am trying to push them to systemd
I don't no nothing about Gnome, but little about systemd: (In reply to Alexandre Rostovtsev from comment #2) > (In reply to Ulenrich from comment #0) > > genkernel->dracut > > Dracut is not needed; I am running genkernel + systemd + gnome-3.8 without > any problems. Surely you are able to hack yourself a pathway around Dracut. But as I dig deeper into systemd: It is all about a sober software stack. Where would there be the services to provide initrd shutdown using genkernel? Using a kernel.org phrase: Your systemd installation would be "tainted" !
(In reply to Pacho Ramos from comment #3) > (In reply to Ulenrich from comment #0) > > Please provide a Gnome38 profile. > > The forum is drowning of ever the same issue > ... > As a side note, I am following "Gnome 3.8" forums thread... and this kind of > problems were being handled... but could people please stop suggesting users > to add multiple hacks to prevent systemd migration? I have seen > recommendations like masking gnome-settings-daemon-3.8 (!), that is > completely unsupported but I haven't replied to that thread because I am > tired of, then, needing to explain again and again why we need systemd and, > finally, people getting angry with me because they think *I* am trying to > push them to systemd Exactly that type of exhaustion I meant using the phrase "forum is drowning". If there would be the directive of a Gnome38 profile all of that weird kind of discussion would end normaly. Because it is clearly stated by the profile what is supported and what is not.
Rethinking about this, maybe would be better to have a "systemd" profile and, then, inherit it from gnome3 one (if we need to add anything) That way, people wanting to migrate from consolekit to systemd (that should be possible since distributions like mageia are not even providing consolekit) but using other desktops would benefit from it. For now it should - Disable consolekit USE flag and enable systemd one - Mask static-libs stuff
Enabling USE=systemd in the profile would make it likely impossible to install systemd due to circular deps e.g. with dbus.
Umm, yes, I see... but I don't know how to solve that :(
(In reply to Pacho Ramos from comment #8) > Umm, yes, I see... but I don't know how to solve that :( @portage, I guess this is similar to bug 175808 or bug 310613 that are hard to fix, no? The idea would be to make portage build stuff with minimum set of flags to try to resolve the circular dep issue and, after that, "unmask" that USE flags. The problem, as usual, is that it's probably much harder to implement than to think :S
(In reply to Michał Górny from comment #7) > Enabling USE=systemd in the profile would make it likely impossible to > install systemd due to circular deps e.g. with dbus. With the exact case of dbus, looks like Arch is simply dropping the dep to prevent the circular dep problem (even enabling systemd for dbus): https://mailman.archlinux.org/pipermail/arch-commits/2012-December/181838.html in our case would be to move it to PDEPEND... but I haven't tested in here on Gentoo :/
(In reply to Pacho Ramos from comment #9) > (In reply to Pacho Ramos from comment #8) > > Umm, yes, I see... but I don't know how to solve that :( > > @portage, I guess this is similar to bug 175808 or bug 310613 that are hard > to fix, no? > > The idea would be to make portage build stuff with minimum set of flags to > try to resolve the circular dep issue and, after that, "unmask" that USE > flags. The problem, as usual, is that it's probably much harder to implement > than to think :S Other idea could be to have a different type of USE flags defined in a future eapi (but this would be for the long term, not for this issue as it would require much more time): - IUSE would behave as currently - We would add something like IUSE_INSTALLED -> we would drop flags that cause this kind of circular dep problems (like "test" and "doc" depending on the package) from IUSE, moving them to IUSE_INSTALLED. When the package is not installed in the system, portage would only take IUSE, while considering IUSE_INSTALLED when the package is present in the system
(In reply to Pacho Ramos from comment #11) [...] > - IUSE would behave as currently > - We would add something like IUSE_INSTALLED Well, not exactly: - IUSE would only have IUSE_INSTALLED contents when the package is already present in the system
bug 468500 shows why this should be done in a systemd profile no matter on the desktop (if we are able to finally enable that flag without causing really difficult to solve circular dep problems)
(In reply to Pacho Ramos from comment #9) > @portage, I guess this is similar to bug 175808 or bug 310613 that are hard > to fix, no? > > The idea would be to make portage build stuff with minimum set of flags to > try to resolve the circular dep issue and, after that, "unmask" that USE > flags. The problem, as usual, is that it's probably much harder to implement > than to think :S Yes, it's a lot of work.
(In reply to Zac Medico from comment #14) > Yes, it's a lot of work. As a side note, what do you think would be better? The portage figuring out what USE flags should be changed or the IUSE* separation I commented before?
(In reply to Pacho Ramos from comment #15) > (In reply to Zac Medico from comment #14) > > Yes, it's a lot of work. > > As a side note, what do you think would be better? Generally, splitting packages when possible it the best way to go. > The portage figuring out what USE flags should be changed This is good for cases where it's simply impossible to split packages in order to solve the circular deps. > or the IUSE* separation I commented before? This seems like an ugly workaround.
(In reply to Michał Górny from comment #7) > Enabling USE=systemd in the profile would make it likely impossible to > install systemd due to circular deps e.g. with dbus. Due this, this bug is probably "CANTFIX" :/, I am lost of ideas about how to improve situation apart of using docs :|
We need to synchronize with bug 481920 (and decide what to do finally :/)
*** This bug has been marked as a duplicate of bug 481920 ***
