The installation of systemd to /usr is wrong according to upstream is it's causing maintaining issues with our sys-fs/udev. This patch could be applied if systemd were correctly in /. --- udev-9999.ebuild +++ udev-9999.ebuild @@ -348,20 +348,7 @@ # install udevadm symlink dosym ../bin/udevadm /sbin/udevadm - - # move udevd where it used to be and prevent it from showing up - # as systemd-udevd named process - mv "${ED}"/{lib/systemd/systemd-udevd,sbin/udevd} || die - rm -r "${ED}"/lib/systemd - - # with systemd installing to /usr/lib/systed having /lib/systemd - # is redudant (and breaking initramfs tools) - local systemddir=$(systemd_get_utildir) - dosym /sbin/udevd ${systemddir}/systemd-udevd - find "${ED}"/${systemddir} -name '*systemd-udev*.service' -exec \ - sed -i -e "/ExecStart/s:/lib/systemd:${systemddir}:" {} + - find "${ED}"/${systemddir} -name '*udevadm*.service' -exec \ - sed -i -e "/ExecStart/s:/usr/bin/udevadm:/bin/udevadm:" {} + + dosym ../lib/systemd/systemd-udevd /sbin/udevd If you are not going to move systemd from /usr to / like upstream wants, and every other distribution is doing too, then we need to move the ownership of all of these files to systemd's tarball since we definately shouldn't be carrying thesetype of hacks in udev's ebuild just to accommendate unstandard installation layout.
(Typing errors. Sorry.) (In reply to comment #0) > The installation of systemd to /usr is wrong according to upstream is it's *it is > all of these files to systemd's tarball since we definately shouldn't be *tarball -> ebuild
These are the files that will be dropped with 198-r6 is systemd doesn't move: /usr/lib/systemd/system/systemd-udevd-control.socket /usr/lib/systemd/system/systemd-udevd-kernel.socket /usr/lib/systemd/system/systemd-udev-settle.service /usr/lib/systemd/system/systemd-udev-trigger.service /usr/lib/systemd/system/systemd-udevd.service /usr/lib/systemd/system/initrd-udevadm-cleanup-db.service Then you can do your own path mangling in the systemd's ebuild. We have no need for carrying these hacks in udev's ebuild. Moving systemd to / is the only way I can see us keeping these in udev's ebuild.
(Typing errors again, sorry!) (In reply to comment #2) > These are the files that will be dropped with 198-r6 is systemd doesn't move: *if
(In reply to comment #2) > Moving systemd to / is the only way I can see us keeping these in udev's these == the files, installed, with no path hacks required. should learn to doublecheck even my bugzie posts everytime. :-) thanks for looking into this, I don't want this to sound like any ultimatum, but you must see the problem too...
Just that if this wasn't clear enough: The bug 462132 happened because systemd uses undefault /usr installation for systemd The way it might show up as ./configure output or such is irrelevant, udev/systemd upstreams says to install systemd to / in those scenarios where eg. /lib is not symlink to /usr/lib What can be done is creating a symlink from /usr/lib/systemd to /lib/systemd after systemd has been moved to /lib/systemd, helps transition and helps those programs work that assume every system using systemd also has the unified /lib, /usr/lib, like Fedora has
Ok, so I've been against moving systemd to / mainly becuase nobody has provided reasonable explanation of why we should force our users to undergo another migration. "Upstream says so" is a really weak argument by itself. However, since we do seem to be running into some visible breakage here, I think a migration may be justified. Perhaps we could wait for systemd-199 to do so?
If you need help working on the migration, I'll gladly help with it, just let me know.
And building udev without systemd is not a hack at all? The whole udev ebuild is a pile of hacks, so I don't see where you are going here. But feel free to move all the deps of systemd to rootfs. Then we'll talk.
What about https://bugs.gentoo.org/show_bug.cgi?id=430470#c20 ?
It is not necessary to move all of the deps of systemd to root. All you have to do is tell systemd users that they must use an initramfs if they have separate /usr, which they are already doing since systemd is installed in /usr currently.
That's a mess against the QA rules, and pointless bloating of rootfs.
(In reply to comment #11) > That's a mess against the QA rules, and pointless bloating of rootfs. Which qa rules? I honestly don't know of any that have anything to do with this. I don't get what you mean by "pointless bloating of rootfs".
I had a brief chat with mgorny on irc, and I understand he is concerned about bug #398051 coming into play with systemd if we do not move all of its dependencies to /. That bug is just a tracker; I do not see any requirement there that we move all of systemd's dependencies to /. I suggested that he look into the ismounted() function in the udev ebuild and how we use it to warn users when they install udev that they may have issues if they are not using an initramfs and /usr is a separate file system.
systemd maintainers, you want to move these files over to systemd to keep on installing to /usr? because that's what I conclude currently from the bug i still don't understand why you are going against upstreams wished here, but i'm not the maintainer so... but sys-fs/udev will be dropping these systemd files since they are sanely maintainable because of the way systemd is installed
(In reply to comment #14) > but sys-fs/udev will be dropping these systemd files since they are sanely > maintainable because of the way systemd is installed *not sanely typo
(In reply to comment #14) > systemd maintainers, you want to move these files over to systemd to keep on > installing to /usr? because that's what I conclude currently from the bug > i still don't understand why you are going against upstreams wished here, > but i'm not the maintainer so... In my chat with mgorny earlier, he expressed concern that putting systemd in / without moving all of its dependencies to / is a violation of Gentoo QA. I don't believe it is however. @samuli: Do you know if there is a qa rule against this?
(In reply to comment #16) > (In reply to comment #14) > > systemd maintainers, you want to move these files over to systemd to keep on > > installing to /usr? because that's what I conclude currently from the bug > > i still don't understand why you are going against upstreams wished here, > > but i'm not the maintainer so... > > In my chat with mgorny earlier, he expressed concern that putting systemd in > / without moving all of its dependencies to / is a violation of Gentoo QA. > > I don't believe it is however. > > @samuli: > Do you know if there is a qa rule against this? well, there is... nothing from / should link against /usr, or it should be avoided at all cost seems like these files should be owned by the systemd ebuild to have the correct ExecStart= in them
Ok, in that case, I'll look into bumping the udev ebuild again if you want and dropping the systemd units.
OK, removed all of these from >=sys-fs/udev-198-r5: <<< sym /usr/lib/systemd/systemd-udevd (this was symlink to /sbin/udevd) <<< obj /usr/lib/systemd/system/systemd-udevd.service <<< obj /usr/lib/systemd/system/systemd-udevd-kernel.socket <<< obj /usr/lib/systemd/system/systemd-udevd-control.socket <<< obj /usr/lib/systemd/system/systemd-udev-trigger.service <<< obj /usr/lib/systemd/system/systemd-udev-settle.service <<< obj /usr/lib/systemd/system/initrd-udevadm-cleanup-db.service This allows us to have clean: mv "${D}"/{lib/systemd/systemd-,sbin/}udevd || die rm -r "${D}"/lib/systemd Let us know if you move systemd to / and we can convert it to the clean solution: dosym /lib/systemd/systemd-udevd /sbin/udevd
(In reply to comment #19) > OK, removed all of these from >=sys-fs/udev-198-r5: > > <<< sym /usr/lib/systemd/systemd-udevd (this was symlink to > /sbin/udevd) > <<< obj /usr/lib/systemd/system/systemd-udevd.service > <<< obj /usr/lib/systemd/system/systemd-udevd-kernel.socket > <<< obj /usr/lib/systemd/system/systemd-udevd-control.socket > <<< obj /usr/lib/systemd/system/systemd-udev-trigger.service > <<< obj /usr/lib/systemd/system/systemd-udev-settle.service > <<< obj /usr/lib/systemd/system/initrd-udevadm-cleanup-db.service This has gone too far. You just intentionally broke a number of systems by leaving systemd users without udev units, you did that in -r5 which is *explicitly* requested by systemd now -- so leaving no working version -- and you didn't even care enough to set a blocker. @qa, could you do something to make Samuli think before he commits?
(In reply to comment #20) > and you didn't even care enough to set a blocker. > @qa, could you do something to make Samuli think before he commits? I should have updated the blocker which was the intention, obviously I forgot. Humans make errors. Sorry. But I'm glad qa@ is involved, if they can help with sanitizing how systemd is being installed here.
Currently there is no udev to work with current systemd-198*. sys-fs/udev-198-r4 allowed by systemd have collision on /usr/lib/systemd/system/initrd-udevadm-cleanup-db.service.
@QA: What do you think about the original request in this bug wrt moving systemd to /? It was stated in comment #11 that this would violate QA rules since it would place binaries in / that link to libraries in /usr. Is this true that it is a qa violation to place binaries in / that link to /usr/lib*? If it is, I think we can make an exception for systemd, because it is an init system, and because upstream recommends installing it in / if your distro does not have the /usr merge and using an initramfs if you have separate /usr.
@QA: Here is what upstream had to say about installing systemd in /usr on a distro that does not have the usr merge. --- Log opened Mon Mar 11 21:36:03 2013 21:36 < WilliamH> poettering: Hey, if you are around, I have a question. 21:37 < WilliamH> poettering: on gentoo, our systemd maintainer is installing everything in /usr, and we do not have / and /usr merged. From autogen.sh, I don't think that's a good idea, 21:37 < WilliamH> poettering: correct? 21:45 < poettering> WilliamH: either you split /usr, or you don't 21:46 < poettering> WilliamH: if you install everything to /usr, but don't merge the dirs 21:46 < poettering> WilliamH: then you get the worst of both 21:46 < poettering> WilliamH: because now your binaries are in different paths than on any other distro 21:46 < poettering> WilliamH: which is totally the opposite of what the usr merge is supposed to achieve: that either path works 21:47 < poettering> so, yeah, it's a *really* bad idea to install everything to /usr without doing the full merge 21:47 < poettering> it's the worst possible choice
You guys could have easily have forced the issue on a version bump (udev/systemd-199). Breaking existing systems was a really fucking stupid move.
(In reply to comment #20) > (In reply to comment #19) > > OK, removed all of these from >=sys-fs/udev-198-r5: > > > > <<< sym /usr/lib/systemd/systemd-udevd (this was symlink to > > /sbin/udevd) > > <<< obj /usr/lib/systemd/system/systemd-udevd.service > > <<< obj /usr/lib/systemd/system/systemd-udevd-kernel.socket > > <<< obj /usr/lib/systemd/system/systemd-udevd-control.socket > > <<< obj /usr/lib/systemd/system/systemd-udev-trigger.service > > <<< obj /usr/lib/systemd/system/systemd-udev-settle.service > > <<< obj /usr/lib/systemd/system/initrd-udevadm-cleanup-db.service > > This has gone too far. You just intentionally broke a number of systems by > leaving systemd users without udev units, you did that in -r5 which is > *explicitly* requested by systemd now -- so leaving no working version -- > and you didn't even care enough to set a blocker. > > @qa, could you do something to make Samuli think before he commits? I'm going to support Samuli here. This is ~arch, breakages happen sometimes. The important thing is he responded right away and fixed it.
(In reply to comment #26) > (In reply to comment #20) > > @qa, could you do something to make Samuli think before he commits? > > I'm going to support Samuli here. This is ~arch, breakages happen sometimes. > The important thing is he responded right away and fixed it. Did he? I've fixed it. He just revbumped it which didn't fix anything. There were still no *working* version matching systemd-198-r2. I removed it but I doubt that portage will like to downgrade it all to working state gracefully. And now I have to fix that mess quickly while I'm stacked up with work. Thank you very much.
I have never seen this before: --- emerge -auDN --verbose=n --color=n world These are the packages that would be merged, in order: Calculating dependencies . ..... done! [ebuild U ] sys-fs/udev-198-r6 [198-r5] [ebuild UD ] sys-fs/udev-197-r8 [198-r5] [ebuild UD ] sys-apps/systemd-198-r1 [198-r2] [blocks B ] sys-apps/systemd ("sys-apps/systemd" is blocking sys-fs/udev-198-r6) !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: ... --- portage wants to upgrade and downgrade at the same time :) At the moment I think of it as laughable Gentoo mainteiners working on three "usr" letters in between directory names for months. There may be coming a time when I will have some hundreds of gadgets in my household, where I want to quickly deploy. I will want a usr merge to easily manage that. Gentoo as a meta distribution should provide the choice. What is that difficult to implement the tools? Multilib and crossdev - all of that I consider hard to implement, but three additional letters in a directory tree?
198-r3 should fix it. But prepare for a new batch of failures. I'd rather commit it p.masked but the breakage Samuli introduced means it has to go live as-is.
(In reply to comment #28) Same here, Ulenrich. I decided to swap back to openrc after trying to work out the block by removing systemd. Bit of a pain since I just spent time masking and unmasking some flags for desired KDE experience. I guess I may wait this one out ;) (In reply to comment #29) > 198-r3 should fix it. But prepare for a new batch of failures. I'd rather > commit it p.masked but the breakage Samuli introduced means it has to go > live as-is. Hi, excuse my ignorance but from the changelog: >Install udev along with systemd again. So systemd will now provide udev also rather then rely on on the seperate udev package? It would be nice to have only one package delivering both for systemd users imo :)
(In reply to comment #29) > 198-r3 should fix it. But prepare for a new batch of failures. I'd rather > commit it p.masked but the breakage Samuli introduced means it has to go > live as-is. You've been told repeatedly to change systemd to install where upstream would put it / and it would have been no problem with simply symlinking /lib/systemd/systemd-udevd to /sbin/udevd and the .service files would have been OK without those seds/hacks Patches have been submitted for review at -dev ML for systemd.eclass to respect pkg-config, move to /, and so forth, and you've pretty much not offered other than "go f* yourself" as response People pretty much were agreeing with sanitizing it, Comment #6, Comment #18, and all the discussion out from this bug And systemd is not yet the default provider. and this is ~arch, and this bug was open so you could move those files over Instead you went the wrong way, again, and put blame on other people, that's very nice This bug is hardly fixed, and if things stay as they are now, we'll have to create another systemd ebuild in Portage just to revert the this madness, I certainly don't trust the current ebuild anymore
Regarding systemd-198-r3: Unbundling udev has caused a lot of headaches so far, and the personalities involved are not making that easier. mgorny: Please try not to be so dismissive of people. I realize that you value your time quite highly, but I think you are creating more of a problem. ssuominien: Breaking systemd was a dick move, accident or not. I have no idea why you felt the need to modify udev-198-r5 at all. It is difficult to trust that this sort of thing will not happen again.
I'm adding this link to this bug as further evidence of the apparent unwillingness of the maintainers to work with anyone regarding sanitizing this ebuild. This is a link to the dev ml where I proposed a patch to make the systemd eclass respect *.pc files when looking up directory paths [1]. [1] http://www.gossamer-threads.com/lists/gentoo/dev/269385?page=last
Sanitizing? So far you've been trying to force your ideas on me with no other explanation that 'I asked Lennart and he said he doesn't like Gentoo installing systemd in /usr'. You've been repeatedly trying to enforce your concept with no respect for my opinion. You've been repeatedly ignoring the fact that I asked (and not once) to ping with new udev versions for review *before* committing it so that I could sync systemd. And now you're even breaking systemd intentionally. That's *unwillingness*.
(In reply to comment #34) > Sanitizing? So far you've been trying to force your ideas on me with no > other explanation that 'I asked Lennart and he said he doesn't like Gentoo > installing systemd in /usr'. > > You've been repeatedly trying to enforce your concept with no respect for my > opinion. You've been repeatedly ignoring the fact that I asked (and not > once) to ping with new udev versions for review *before* committing it so > that I could sync systemd. And now you're even breaking systemd > intentionally. That's *unwillingness*. I've been informing you with changes on systemd git that needed changes also in systemd's ebuild before releases. WilliamH and others have tried to make you sanitize systemd's install paths for a while now. It was not pretty, but we carried around some hacks to accommendate that like shown in Comment #0. The hacks keps piling up, like with udevadm and initrd-udevadm-cleanup-db. You still refused to listen, providing not much else than your way or highway. Acknowlidging you can't be convinced to use sane install prefix, you were offered alternative solution, moving these few service files and the symlink over to systemd's ebuild. Still, the response was something else than warming. Finally we dropped the hacks from the ebuild, and left this bug for you to handle rest of the way. So you were unwilling to change to what Gentoo's udev maintainers wanted, what upstream systemd maintainers wanted, and you even refused to take the fallback of just migrating these few files over. Instead you decided to go all teen angst and bundle the whole udev back to systemds ebuild. Then wondering in IRC why your printer isn't working, well, propably because you aren't using correct version of sys-fs/udev from tree where this is patched -- and not patched in systemd. I find that a bit funny. Overall you were hard to work with to begin with, but this went over the top by far.
(In reply to comment #35) > I've been informing you with changes on systemd git that needed changes also > in systemd's ebuild before releases. Yes, usually in form of IRC messages in middle of the night. So I could happily read them in the morning when udev was already committed. > WilliamH and others have tried to make you sanitize systemd's install paths > for a while now. Sanitize? How are installing into a single prefix not sane? > Acknowlidging you can't be convinced to use sane install prefix, you were > offered alternative solution, moving these few service files and the symlink > over to systemd's ebuild. > Still, the response was something else than warming. > Finally we dropped the hacks from the ebuild, and left this bug for you to > handle rest of the way. Let me make this clear: you first agreed on one solution, then decided you do not like it and opened this bug. I've disliked your solution, so you decided to force it on me through committing an intentional breakage. Shortly saying, this is blackmail followed by terrorism. You're selling breakage to systemd users just to force your wannabes on me. > Instead you decided to go all teen angst and bundle the whole udev back to > systemds ebuild. You've proven more than once that you don't want to co-operate. I don't see a problem with that since we have virtual/udev now. You're just bending facts to force your wannabes. > Then wondering in IRC why your printer isn't working, well, > propably because you aren't using correct version of sys-fs/udev from tree > where this is patched -- and not patched in systemd. I find that a bit funny. You could at least cite exactly what I say. If you're really interested, I was fixing the printer the whole morning (and literally having my hands covered in toner), and had to stop because I've discovered that you committed an awful breakage to the tree. So you could at least have enough respect to let me finish doing that after I fixed the mess you've caused. I've did the best thing I could do with the very limited time you gave me. Next time you could think a bit before committing. Or just leave Gentoo, many people will thank you for that, I assure you.
I vote for Rays wish: systemd providing virtual/udev https://bugs.gentoo.org/show_bug.cgi?id=462750#c30 @mgorny, wouldn't it by far a more "recreational" experience to pick and choose any Gentoo udev patches by hand ? Than this 'non'-team work ...
(In reply to comment #37) > I vote for Rays wish: systemd providing virtual/udev > https://bugs.gentoo.org/show_bug.cgi?id=462750#c30 That is exactly 198-r3 (plus virtual/udev-197-r2) people want to kill me for. > @mgorny, > wouldn't it by far a more "recreational" experience > to pick and choose any Gentoo udev patches by hand ? > Than this 'non'-team work ... I'd personally prefer going the vanilla way for now and seeing how it works out.
(In reply to comment #36) > (In reply to comment #35) > > I've been informing you with changes on systemd git that needed changes also > > in systemd's ebuild before releases. > > Yes, usually in form of IRC messages in middle of the night. So I could > happily read them in the morning when udev was already committed. As it should be, udev's consumers follow udev, not the otherway around. Entirely different story if systemd wasn't messed up in profiles, marked stable and the default init system. None of which is currently true, which makes systemd consumers of udev, no more, no less than eg. gnome-base/gvfs. We are talking about ~arch here. > Let me make this clear: you first agreed on one solution, then decided you > do not like it and opened this bug. I've disliked your solution, so you > decided to force it on me through committing an intentional breakage. I told you very beginning I'm not happy with being forced to sed these paths to be correct due to systemd diverging from the recommended install / root. Explicitely told you I was OK for it this one time. Then the files to be sedded started growing up, ie. this udevadm service file. > Shortly saying, this is blackmail followed by terrorism. You're selling > breakage to systemd users just to force your wannabes on me. I don't even know what that means, but sounds childish. > > Instead you decided to go all teen angst and bundle the whole udev back to > > systemds ebuild. > > You've proven more than once that you don't want to co-operate. I don't see > a problem with that since we have virtual/udev now. You're just bending > facts to force your wannabes. I've spent so much time making things work for both openrc and systemd, that this is just lying or trolling. I've worked with you numerous times and we have talked privately, most often about live versions in preparation for releases. > I've did the best thing I could do with the very limited time you gave me. > Next time you could think a bit before committing. Or just leave Gentoo, > many people will thank you for that, I assure you. Likewise, I've spent too much time discussing about you privately amongst people already today. I'd still prefer to try to work with you, but sadly you seem to insist on closing that door for good...
I do not know whether this bug report is the correct place to report my issue but it seems related, so please forgive me if I'm mistaken: Currently, I have the following blocker when trying to update my @world set or try to update systemd and udev: $ sudo emerge -a1v systemd udev [ebuild U ] sys-apps/systemd-198-r4 [198-r1] USE="kmod pam tcpd -acl -audit -cryptsetup -doc% -efi -gcrypt -gudev% -http -introspection% -lzma -python -qrcode (-selinux) -vanilla -xattr" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7" 0 kB [ebuild U ] sys-fs/udev-198-r6 [198-r2] USE="gudev hwdb introspection keymap kmod openrc -acl -doc (-selinux) -static-libs" 3 kB [blocks B ] sys-fs/udev ("sys-fs/udev" is blocking sys-apps/systemd-198-r4) [blocks B ] sys-apps/systemd ("sys-apps/systemd" is blocking sys-fs/udev-198-r6) I tried solving it by uninstalling udev and updating systemd (as systemd seems to bundle udev now, does it not?), but somehow udev was pulled back in. How should I proceed from here? Thanks in advance.
(In reply to comment #40) equery depends sys-fs/udev
(In reply to comment #40) > I do not know whether this bug report is the correct place to report my > issue but it seems related, so please forgive me if I'm mistaken: > > Currently, I have the following blocker when trying to update my @world set > or try to update systemd and udev: > > $ sudo emerge -a1v systemd udev > [ebuild U ] sys-apps/systemd-198-r4 [198-r1] USE="kmod pam tcpd -acl > -audit -cryptsetup -doc% -efi -gcrypt -gudev% -http -introspection% -lzma > -python -qrcode (-selinux) -vanilla -xattr" PYTHON_SINGLE_TARGET="python2_7" > PYTHON_TARGETS="python2_7" 0 kB > [ebuild U ] sys-fs/udev-198-r6 [198-r2] USE="gudev hwdb introspection > keymap kmod openrc -acl -doc (-selinux) -static-libs" 3 kB Most likely flags enabled on virtual/udev don't match those on systemd. I have committed a profile update which should sync that.
@Martin, you could try emerge --verbose virtual/udev as this also has to upgrade ...
Now, I managed to emerge =systemd-198-r5 along with =virtual/udev-197-r2 after uninstalling sys-fs/udev manually. Now I have: $ emerge -pv systemd virtual/udev [ebuild R ] sys-apps/systemd-198-r5 USE="gudev introspection kmod pam tcpd -acl -audit -cryptsetup -doc -efi -gcrypt -http -lzma -python -qrcode (-selinux) -vanilla -xattr" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7" 2,091 kB [ebuild R ] virtual/udev-197-r2 USE="gudev hwdb introspection keymap kmod (-selinux) -static-libs" 0 kB But a world update keeps pulling in sys-fs/udev (via virtual/udev if I correctly read the output of emerge --tree ...): $ sudo emerge -uDNav @world --tree [...] [nomerge ] media-sound/banshee-2.6.0 USE="aac bpm cdda encode udev web youtube -boo -daap -doc -ipod -karma -mtp {-test}" [nomerge ] dev-dotnet/gudev-sharp-0.1 [nomerge ] virtual/udev-197-r2 USE="gudev hwdb introspection keymap kmod (-selinux) -static-libs" [ebuild N ] sys-fs/udev-198-r6 USE="gudev hwdb introspection keymap kmod openrc -acl -doc (-selinux) -static-libs" 2,094 kB [...] [blocks B ] sys-apps/systemd ("sys-apps/systemd" is blocking sys-fs/udev-198-r6) [blocks B ] sys-fs/udev ("sys-fs/udev" is blocking sys-apps/systemd-198-r5) Total: 28 packages (23 upgrades, 2 new, 1 in new slot, 2 reinstalls), Size of downloads: 507,506 kB Conflict: 2 blocks (2 unsatisfied) * Error: The above package list contains packages which cannot be * installed at the same time on the same system. (sys-fs/udev-198-r6::gentoo, ebuild scheduled for merge) pulled in by >=sys-fs/udev-171[gudev] required by (media-video/cheese-3.6.2::gnome, installed) >=sys-fs/udev-197-r8[gudev,hwdb,introspection,keymap,kmod] required by (virtual/udev-197-r2::gentoo, installed) (sys-apps/systemd-198-r5::gentoo, installed) pulled in by >=sys-apps/systemd-31 required by (gnome-extra/gnome-screensaver-3.6.1::gnome, installed) >=sys-apps/systemd-39 required by (media-sound/pulseaudio-3.0::gentoo, installed) >=sys-apps/systemd-44 required by (x11-misc/colord-0.1.28::gentoo, installed) >=sys-apps/systemd-44-r1 required by (sys-apps/dbus-1.6.8-r1::gentoo, installed) >=sys-apps/systemd-186 required by (sys-apps/accountsservice-0.6.30::gentoo, installed) >=sys-apps/systemd-44-r1[pam] required by (sys-auth/pambase-20120417-r1::gentoo, installed) sys-apps/systemd required by (net-print/cups-1.6.2::gentoo, ebuild scheduled for merge) sys-apps/systemd required by (sys-power/upower-0.9.20-r2::gentoo, installed) sys-apps/systemd required by (sys-auth/polkit-0.110::gentoo, installed) >=sys-apps/systemd-31 required by (gnome-base/gnome-settings-daemon-3.6.4::gentoo, installed) >=sys-apps/systemd-31 required by (net-misc/networkmanager-0.9.6.4-r1::gentoo, installed) >=sys-apps/systemd-183 required by (gnome-base/gnome-session-3.6.2-r2::gentoo, installed) >=sys-apps/systemd-31 required by (gnome-base/gnome-shell-3.6.3.1::gentoo, installed) >=sys-apps/systemd-31 required by (gnome-base/gnome-control-center-3.6.3-r1::gentoo, installed) sys-apps/systemd required by (gnome-base/gvfs-1.14.2::gentoo, installed) >=sys-apps/systemd-39[pam] required by (gnome-base/gdm-3.6.2::gnome, installed)
Let's not discuss blocker problems on this bug report please.
