On Wed, Mar 15 2017, Kai Krakow wrote:
> Am Tue, 14 Mar 2017 13:00:17 -0400
> schrieb allan gottlieb <gottl...@nyu.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.
I don't remember there being any such output but am not sure. Following
alan's reply I let the emerge world update proceed and the build caused
completed. (Then I hit the infinite @preserved-rebuild bug, but that is
a different issue, I believe)
> 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.
thank you,
allan
