1 |
On 12/08/2013 12:19, Tanstaafl wrote: |
2 |
> On 2013-08-11 2:38 PM, Samuli Suominen <ssuominen@g.o> wrote: |
3 |
>> On 11/08/13 21:13, Neil Bothwick wrote: |
4 |
>>> There was a blocker (small b) because virtual/udev needed sys-fs/udev |
5 |
>>> and |
6 |
>>> that gave a blocker that uninstalled eudev. |
7 |
> |
8 |
>> I believe it's 'b' if user doesn't have sys-fs/eudev in |
9 |
>> /var/lib/portage/world, but 'B' if he does |
10 |
>> As in, difference is soft and hard blocker depending if the wanted |
11 |
>> implementation is recorded in the world file or not |
12 |
> |
13 |
> Well, in my opinion, that just seems wrong. Why does it prefer udev, if |
14 |
> *neither* is in the world file? |
15 |
> |
16 |
> In my opinion, it should be a 'B' blocker in both cases. It absolutely |
17 |
> should not automatically uninstall eudev and install udev, potentially |
18 |
> leaving the system in an unbootable state. |
19 |
> |
20 |
> But... as long as the conflict is there (for those who actually look |
21 |
> for such things) and I can deal with it appropriately - ie, if a small b |
22 |
> blocker and it wants to remove eudev and install udev, I just wait until |
23 |
> ... |
24 |
> |
25 |
> Hmmm... so is it eudev that would need to be updated to 'fix' this? Or |
26 |
> virtual/udev? Or both? |
27 |
> |
28 |
|
29 |
It has to do with how virtuals work. |
30 |
|
31 |
If you have the virtual in @world, and none of the packages that satisfy |
32 |
the virtual are in world, then portage is free to do whatever it deems |
33 |
correct to satisfy the virtual. This is what it did, and it is rather |
34 |
important you understand why this is so. |
35 |
|
36 |
If you have the virtual in world, and one of the packages that satisfy |
37 |
the virtual are in world, then portage will not uninstall that package |
38 |
and instead obey your instruction. |
39 |
|
40 |
Portage does not work according to whatever we think ought to be |
41 |
logical. Portage works according to the PMS spec. In this case, it did |
42 |
what you asked, which is not what you wanted. |
43 |
|
44 |
|
45 |
|
46 |
-- |
47 |
Alan McKinnon |
48 |
alan.mckinnon@×××××.com |