Summary: | virtual/dev-manager-0 requiring sys-apps/busybox[mdev] when installed sys-fs/udev version is not marked stable | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Ronie Henrich <ronie> |
Component: | [OLD] Core system | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED INVALID | ||
Severity: | critical | CC: | base-system, floppym |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Ronie Henrich
2012-12-20 03:38:53 UTC
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. |