Re: [gentoo-user] Re: 'emerge --update @world -pv' keeps trying to upgrade to a masked package

[Alan McKinnon]

On 14/10/2015 03:53, Dale wrote:
> Marat BN wrote:
>> Ah, I think I figured out what was the problem.  Looked down further in
>> the Portage output, and saw this:
>>
>> The following mask changes are necessary to proceed:
>>  (see "package.unmask" in the portage(5) man page for more details)
>> # required by gnome-extra/nm-applet-1.0.6::gentoo
>> # required by net-misc/networkmanager-pptp-1.0.6::gentoo[gtk]
>> # required by @selected
>> # required by @world (argument)
>> # /etc/portage/package.mask:
>> # 2015-09-19--01
>> =net-misc/networkmanager-1.0.6
>> # required by net-misc/networkmanager-pptp-1.0.6::gentoo[gtk]
>> # required by @selected
>> # required by @world (argument)
>> # /etc/portage/package.mask:
>> # 2015-09-14--01
>> =gnome-extra/nm-applet-1.0.6
>> # required by net-misc/networkmanager-1.0.6::gentoo[bluetooth]
>> # required by gnome-extra/nm-applet-1.0.6::gentoo
>> # required by net-misc/networkmanager-pptp-1.0.6::gentoo[gtk]
>> # required by @selected
>> # required by @world (argument)
>> # /etc/portage/package.mask:
>> # 2015-06-22--01
>> =net-wireless/bluez-5.33
>>
>>
>> It appears that 'net-misc/networkmanager-1.0.6' was being pulled in by
>> 'gnome-extra/nm-applet-1.0.6::gentoo',
>> 'net-misc/networkmanager-pptp-1.0.6::gentoo[gtk]', and so on, and these
>> were just being reported further down below.
>>
>> So I added them to '/etc/portage/package,mask' as well and the problem
>> went away.
>>
>>
>> -- Marat
>>
>> -------- Original Message --------
>> Subject: 'emerge --update @world -pv' keeps trying to upgrade to a
>> masked package
>> From: Marat BN <maratbn@×××××.com>
>> To: gentoo-user@l.g.o
>> Date: 10/13/2015 05:53 PM
>>
>>> Hello there,
>>>
>>> I'm having a curious problem trying to update my system.
>>>
>>> I issue the command:
>>>
>>> emerge --update @world -pv
>>>
>>>
>>> Portage comes back with the following:
>>>
>>> !!! Multiple package instances within a single package slot have been pulled
>>> !!! into the dependency graph, resulting in a slot conflict:
>>>
>>> net-wireless/bluez:0
>>>
>>>    (net-wireless/bluez-4.101-r9:0/0::gentoo, installed) pulled in by
>>>        net-wireless/bluez:0/0= required by
>>> (media-sound/pulseaudio-5.0-r7:0/0::gentoo, installed)
>>>                                            ^^^^^
>>>
>>>
>>>
>>>        <net-wireless/bluez-5 required by
>>> (net-wireless/blueman-1.23-r2:0/0::maratbn, installed)
>>>        ^                                     ^
>>>
>>>
>>>
>>>
>>>    (net-wireless/bluez-5.33:0/3::gentoo, ebuild scheduled for merge)
>>> pulled in by
>>>        >=net-wireless/bluez-5 required by
>>> (net-misc/networkmanager-1.0.6:0/0::gentoo, ebuild scheduled for merge)
>>>        ^^                                     ^
>>>
>>>
>>>
>>>
>>>
>>>
>>> But I have the following line in my '/etc/portage/package.mask':
>>>
>>> =net-misc/networkmanager-1.0.6:0/0::gentoo
>>>
>>>
>>> So doesn't this tell portage not to upgrade to it?   Why does it still
>>> schedule it for merge?
>>>
>>>
>>> Thanks a lot,
>>> Marat
>>>
>
> I started to post that it looked like some other package was pulling it
> in but portage's output is sometimes cryptic at best.  Sometimes I can
> figure it out but usually, I have to get Alan or Neil to pull out their
> magic decoder ring and uncrypt the thing.
>
> Anyway, glad you got it sorted out and all is well again.


To figure out that "required by/pulled in by/installed" listing, you
have to think like a programmer. That whole listing is not so much
portage telling you what it will do, it's portage telling you how it got
to the point where there's a problem. Think of it like debugger output -
emerge runs, there's a problem and the dev asks for a memory dump of the
dep tree emerge has evaluated so far.

A little bit lower you find the helpful hint the some judicious
unmasking might get around it. But what's really missing is a clear
message about a mask.

Portage is often like a 10 year old telling you why they are upset. Lots
of tears and wailing, but no real description of /why/... :-)

-- 
Alan McKinnon
alan.mckinnon@×××××.com