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


Reply via email to