I am getting the following error when running "emerge -pv --depclean": * Dependencies could not be completely resolved due to * the following required packages not being installed: * * sys-apps/busybox[mdev] pulled in by: * virtual/dev-manager-0 After doing some research and debug I found out that the aforementioned error started after these two changes: 24 Nov 2012; Samuli Suominen <ssuominen@gentoo.org> dev-manager-0.ebuild: Pull in virtual/udev instead of sys-fs/udev wrt #444398 by Richard Yao 24 Nov 2012; Samuli Suominen <ssuominen@gentoo.org> udev-146-r1.ebuild, udev-149.ebuild, udev-151-r4.ebuild, udev-164-r2.ebuild: Reset keywording back to ~arch since these can't be considered stable anymore. Use at your own risk. Before 24 Nov 2012: * sys-fs/udev-164-r2 installed * sys-fs/udev is a provider in virtual/dev-manager-0 * sys-fs/udev-164-r2 is marked stable for x86 * "emerge -pv --depclean" OK After 24 Nov 2012: * sys-fs/udev-164-r2 installed * virtual/udev replaced sys-fs/udev as a provider in virtual/dev-manager-0 * sys-fs/udev-164-r2 not marked stable for x86 anymore * "emerge -pv --depclean" complaints that virtual/dev-manager-0 requires sys-apps/busybox[mdev] After adding =sys-fs/udev-164-r2 to /etc/portage/package.accept_keywords, "emerge -pv --depclean" stopped complaining. It seems that "emerge -pv --depclean" is not considering a installed package as a provider when that package is not marked stable.
It does not consider packages which are not visible when resolving dependencies. udev-164-r2 is no longer visible on a stable system unless you add it to package.keywords. You should upgrade to udev-171, which would also resolve this. I would say portage is operating as-designed; there is no bug here.
Considering this "emerge -pv --depclean" behavior, I regular user probably is going to activate mdev useflag for sys-apps/busybox and recompile sys-apps/busybox. Then sys-fs/udev is going to be removed after running "emerge --depclean", probably leading to a unbootable system. Right?
Two questions: When is the last time you ran a world update? Do you have udev-171 in package.mask?
I do trivial world updates on a weekly basis. I only do a sys-fs/udev update when updating the kernel. A kernel + sys-fs/udev update requires testing before updating that on a production server. But my point is that anyone with a keyworded sys-fs/udev installed is going to get a message asking to enable mdev useflag for sys-apps/busybox. Working as designed or not, a wrong message is and will always be a bug.
I might have the wrong mindset here, so I'm passing this onto the portage maintainers and base-system for a second opinion.
Comment #1 is correct. This is not a bug. The fix is to either upgrade udev to 171 or to add the version of udev you are using to /etc/portage/package.keywords until you can upgrade.
(In reply to comment #6) > Comment #1 is correct. > This is not a bug. > > The fix is to either upgrade udev to 171 or to add the version of udev you > are using to /etc/portage/package.keywords until you can upgrade. Exactly. The part of the ChangeLog from Comment #0 where is says resetting older versions back to ~arch is done purposely, the older versions are known to have so severe issues they are far more unstable than 171 or 196 and should only be used in few extremely rare cases where you can't boot a newer kernel yet. I'm closing this bug, since nothing is to be done here.
(In reply to comment #6) > Comment #1 is correct. > This is not a bug. > > The fix is to either upgrade udev to 171 or to add the version of udev you > are using to /etc/portage/package.keywords until you can upgrade. I know that, but what I am trying to say is that the error given by "emerge -pv --depclean" is misleading. My opinion is that it should not be asking for sys-apps/busybox[mdev] when another provider (sys-fs/udev) is already installed. To prevent mistakes, the message given by "emerge -pv --depclean" could be something like the following: * Dependencies could not be completely resolved due to * the following required packages not being installed: * * sys-fs/udev-164-r2::gentoo (masked by: ~x86 keyword) pulled in by: * virtual/dev-manager-0 If fixing that message is not an option, at least consider a news item for users to be aware of the solution.
(In reply to comment #8) > My opinion is that it should not be asking > for sys-apps/busybox[mdev] when another provider (sys-fs/udev) is already > installed. That would be a variant of bug #164457. > To prevent mistakes, the message given by "emerge -pv --depclean" could be > something like the following: > * Dependencies could not be completely resolved due to > * the following required packages not being installed: > * > * sys-fs/udev-164-r2::gentoo (masked by: ~x86 keyword) pulled in by: > * virtual/dev-manager-0 Yeah, that would a good way to handle bug #164457 for cases where one of the choices is already installed.
