[gentoo-user] Re: some capital B blockers in world update

[Kai Krakow]

Am Tue, 14 Mar 2017 13:00:17 -0400
schrieb allan gottlieb <gottlieb@×××.edu>:

> On Tue, Mar 14 2017, Alan McKinnon wrote:
>
> > On 14/03/2017 16:43, allan gottlieb wrote:
> >> I update roughly twice a week.  On one machine (full output below)
> >> I was told that libinput and evdev are blocking xorg-drivers
> >>
> >> [blocks B ] <x11-drivers/xf86-input-libinput-0.20.0
> >> ("<x11-drivers/xf86-input-libinput-0.20.0" is blocking
> >> x11-base/xorg-drivers-1.19)
> >> [blocks B ] <x11-drivers/xf86-input-evdev-2.10.4
> >> ("<x11-drivers/xf86-input-evdev-2.10.4" is blocking
> >> x11-base/xorg-drivers-1.19)
> >>
> >> However the merge does propose to update xorg-drivers
> >> [ebuild U ] x11-base/xorg-drivers-1.19 [1.18-r1] VIDEO_CARDS="-ark%
> >> -i915% -i965% (-newport) -sis%"
> >>
> >> It also proposes to update libinput and evdev
> >> [ebuild     U  ]   x11-drivers/xf86-input-libinput-0.24.0 [0.19.0]
> >> [ebuild     U  ]  x11-drivers/xf86-input-evdev-2.10.5 [2.10.3]
> >>
> >> I do see that the versions of libinput and evdev to be used are
> >> higher than the versions that would block xorg-drivers.  I am
> >> wondering why in this case emerge is telling me about the block
> >> (in red with a capital B) and more importantly would appreciate
> >> confirmation that I should let the emerge proceed.
> >
> >
> > Portage found a solution that satisfies all constraints, so you
> > should let it proceed.
> >
> > Did you run emerge with -v to get the above?
> > That looks like portage is doing it's usual -v thing which is to
> > core dump to your console in the hope that maybe you can figure it
> > out and you are willing to play the game called "let's find out
> > what portage thinks it means today!"
> >
> > I don't understand why those blockers are marked hard, as portage
> > found a solution. The blocker lines are really telling you why
> > portage wants to upgrade your libinput and evdev drivers - the
> > current ones won't work with your current drivers.
> >
> > Which is all totally pointless, as newer versions of everything are
> > available and you want a full update. There's very little point in
> > software going to great lengths to tell you why it won't keep old
> > versions when you explicitly told it to not keep old versions :-)
>
> Thank you for the confirmation!  I also doubt the use of B when b
> would be appropriated.  No this was not a --verbose run.  I would
> guess that output would be even less illuminating.

Portage usually has such problems when it needs to resolve blockers
involving package rebuilds involving a subslot upgrade. It would be
nice to see the output below the build list which usually gives hints
how to manually resolve this.

The two package blocking each other could then be first upgraded using

# emerge -1a package1 package2

where one of those is the package which needs a subslot rebuild.

This usually then pulls in the rest of the upgrades, at least
partially. A subsequent "emerge -DNua world" then should work as
expected.

I think this is a bug in the dependency resolver.

-- 
Regards,
Kai

Replies to list-only preferred.