On 12/08/2013 12:19, Tanstaafl wrote: > On 2013-08-11 2:38 PM, Samuli Suominen <ssuomi...@gentoo.org> wrote: >> On 11/08/13 21:13, Neil Bothwick wrote: >>> There was a blocker (small b) because virtual/udev needed sys-fs/udev >>> and >>> that gave a blocker that uninstalled eudev. > >> I believe it's 'b' if user doesn't have sys-fs/eudev in >> /var/lib/portage/world, but 'B' if he does >> As in, difference is soft and hard blocker depending if the wanted >> implementation is recorded in the world file or not > > Well, in my opinion, that just seems wrong. Why does it prefer udev, if > *neither* is in the world file? > > In my opinion, it should be a 'B' blocker in both cases. It absolutely > should not automatically uninstall eudev and install udev, potentially > leaving the system in an unbootable state. > > But... as long as the conflict is there (for those who actually look > for such things) and I can deal with it appropriately - ie, if a small b > blocker and it wants to remove eudev and install udev, I just wait until > ... > > Hmmm... so is it eudev that would need to be updated to 'fix' this? Or > virtual/udev? Or both? >
It has to do with how virtuals work. If you have the virtual in @world, and none of the packages that satisfy the virtual are in world, then portage is free to do whatever it deems correct to satisfy the virtual. This is what it did, and it is rather important you understand why this is so. If you have the virtual in world, and one of the packages that satisfy the virtual are in world, then portage will not uninstall that package and instead obey your instruction. Portage does not work according to whatever we think ought to be logical. Portage works according to the PMS spec. In this case, it did what you asked, which is not what you wanted. -- Alan McKinnon alan.mckin...@gmail.com