| View previous topic :: View next topic |
| Author |
Message |
tuxmainy
n00b
Joined: 15 Nov 2016
Posts: 8
|
 Posted: Tue Nov 15, 2016 9:23 pm Post subject: disappointed by blocking ebuilds trap - please motivate :) |
 |
|
Hi all,
I am using Gentoo since 2004. I always liked the minimal way it worked. You want htop? No problem, emerge htop and you will get htop. And only htop.
BUT last evening I really thought about switching to another distribution. I just wanted to start a world update. So I did:
| Code: |
emerge --sync
emerge -vtauD --newuse world
|
awaiting to double check the packages and just start the update I got the following:
| Code: |
!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:
dev-lang/perl:0
(dev-lang/perl-5.22.2:0/5.22::gentoo, ebuild scheduled for merge) pulled in by
=dev-lang/perl-5.22* required by (virtual/perl-Scalar-List-Utils-1.410.0:0/0::gentoo, ebuild scheduled for merge)
^ ^^^^^
(and 17 more with the same problem)
(dev-lang/perl-5.20.2:0/5.20::gentoo, installed) pulled in by
dev-lang/perl:0/5.20=[-build(-)] required by (dev-perl/Authen-SASL-2.160.0-r1:0/0::gentoo, installed)
^^^^^^^^
(and 28 more with the same problem)
x11-libs/libxcb:0
(x11-libs/libxcb-1.12:0/1.12::gentoo, ebuild scheduled for merge) pulled in by
(no parents that aren't satisfied by other packages in this slot)
(x11-libs/libxcb-1.11.1:0/1.11.1::gentoo, installed) pulled in by
>=x11-libs/libxcb-1.9.1:0/1.11.1=[abi_x86_64(-)] required by (x11-libs/xcb-util-image-0.4.0:0/0::gentoo, installed)
^^^^^^^^^^
(and 4 more with the same problem)
NOTE: Use the '--verbose-conflicts' option to display parents omitted above
It may be possible to solve this problem by using package.mask to
prevent one of those packages from being selected. However, it is also
possible that conflicting dependencies exist such that they are
impossible to satisfy simultaneously. If such a conflict exists in
the dependencies of two different packages, then those packages can
not be installed simultaneously. You may want to try a larger value of
the --backtrack option, such as --backtrack=30, in order to see if
that will solve this conflict automatically.
For more information, see MASKED PACKAGES section in the emerge man
page or refer to the Gentoo Handbook.
!!! All ebuilds that could satisfy "x11-base/xorg-server:0/1.17.4=" have been masked.
!!! One of the following masked packages is required to complete your request:
- x11-base/xorg-server-1.17.4::gentoo (masked by: )
(dependency required by "x11-drivers/xf86-input-keyboard-1.8.1::gentoo" [installed])
(dependency required by "x11-base/xorg-drivers-1.18-r1::gentoo[input_devices_keyboard]" [ebuild])
(dependency required by "x11-base/xorg-server-1.18.4::gentoo[xorg]" [ebuild])
(dependency required by "x11-drivers/xf86-video-amdgpu-1.1.0::gentoo" [ebuild])
For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.
|
Uh? You even scrolled here? Then you may be interested in my thoughts about that 
What just happened to portage? I fixed a lot of portage problems. But even after more than 10 years I have absolutely no clue what the problem is neither how to solve it. Guys, is that the way it should work? In my opinion (and yes, MY OPINION) thinks got wrong with portage in the last years. It became to complex over the years. Strange version dependencies syntaxes were added, it started to try to handle conflicts by itself etc etc etc.
Dear community, I REALLY THINK we have to discuss about the further life of the portage NOW.
regards
Daniel |
|
| Back to top |
|
 |
asturm
Developer
Joined: 05 Apr 2007
Posts: 8936
|
| Posted: Tue Nov 15, 2016 9:29 pm Post subject: |
|
|
| Code: | It may be possible to solve this problem by using package.mask to
prevent one of those packages from being selected. However, it is also
possible that conflicting dependencies exist such that they are
impossible to satisfy simultaneously. If such a conflict exists in
the dependencies of two different packages, then those packages can
not be installed simultaneously. You may want to try a larger value of
the --backtrack option, such as --backtrack=30, in order to see if
that will solve this conflict automatically. |
|
|
| Back to top |
|
|
djdunn
l33t
Joined: 26 Dec 2004
Posts: 810
|
| Posted: Wed Nov 16, 2016 12:22 am Post subject: |
|
|
but its telling you exactly what is wrong
!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:
!!! All ebuilds that could satisfy "x11-base/xorg-server:0/1.17.4=" have been masked.
!!! One of the following masked packages is required to complete your request:
- x11-base/xorg-server-1.17.4::gentoo (masked by: )
_________________
“Music is a moral law. It gives a soul to the Universe, wings to the mind, flight to the imagination, a charm to sadness, gaiety and life to everything. It is the essence of order, and leads to all that is good and just and beautiful.”
― Plato |
|
| Back to top |
|
|
albright
Advocate
Joined: 16 Nov 2003
Posts: 2588
Location: Near Toronto
|
| Posted: Wed Nov 16, 2016 2:18 am Post subject: |
|
|
that part could be a little clearer
there are many threads on the perl blockage
and it is a mess for some; see my mess
here:
https://forums.gentoo.org/viewtopic-t-1051448-highlight-perl.html
_________________
.... there is nothing - absolutely nothing - half so much worth
doing as simply messing about with Linux ...
(apologies to Kenneth Graeme) |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 8936
|
| Posted: Wed Nov 16, 2016 7:24 am Post subject: |
|
|
| It's actually not perl related most of the time. |
|
| Back to top |
|
|
tuxmainy
n00b
Joined: 15 Nov 2016
Posts: 8
|
| Posted: Wed Nov 16, 2016 8:28 am Post subject: |
|
|
Hi,
I am happy that my rude post did lead to this answers. Thanks so far.
But the answers of asturm and djdunn don't really target my intention.
Yes I could add "--backtrack=30" but that would neither answer the question of why this problem exists nor what happend to portage that you need to upsize the backtrack. And as albright correctly noticed "masked by:" is not very helpfully. BTW: I looked at the listed ebuilds and I can't see why it is pulling in xorg-server-1.17 and not xorg-server-1.18 (which is newer and stable). Maybe 1.17 is pulled in by another ebuild but then why that block/mask happend?
All that none comprehensible stuff leads to one result: portage is to complex, otherwise it would be easy to understand. So again: something went wrong the last years and I really think we have to set portage on a diet. I as a software devloper know that it is hard to cut out "features" of a software (portage) or to completely rewrite software. But I also know that trying to make a software 100% aware of every situation is resulting in a super bloated software which neither the devloper nor the user is able to handle anymore. And I have the feeling that exactly that happend. We - as a community - added a new dependency here, a new "auto unblock" feature there and a new when this do that algorithm to make a small piece working. And now we have a complex software that everyone needs to use every day but which isn't easy to handle anymore...
regards
Daniel
PS: Yes, --backtrack=30 did the trick. But once again: What happend? Why did it happen? Why didn't I needed that option the last 10 years? Why has portage to bother me with that? and so on and so far... I am a Gentoo user because I am interested in the "WHY"  |
|
| Back to top |
|
|
Genone
Retired Dev
Joined: 14 Mar 2003
Posts: 9530
Location: beyond the rim
|
| Posted: Wed Nov 16, 2016 10:15 am Post subject: |
|
|
| tuxmainy wrote: | | But I also know that trying to make a software 100% aware of every situation is resulting in a super bloated software which neither the devloper nor the user is able to handle anymore. And I have the feeling that exactly that happend. We - as a community - added a new dependency here, a new "auto unblock" feature there and a new when this do that algorithm to make a small piece working. And now we have a complex software that everyone needs to use every day but which isn't easy to handle anymore... |
You'd have to convince certain people that occasional build-/runtime issues aren't the end of the world. Because a lot of the new dependency handling issues of the last couple years is a result of attempting to prevent build-/runtime problem with additional constraints in the dependency handling phase (REQUIRED_USE and subslots to name a few). Which is a perfectly valid goal, unfortunately there are no perfect means to accomplish it. Even for me (as former portage developer that is quite familiar with the used concepts) the results / errors have become more and more cryptic over the last years. To be fair, I haven't actually used Gentoo or Portage for several years and can only go by what I see here on the forums, so I've no idea if the overall situation has become better or worse over time. But I've never been a fan of "smart" software where it's almost impossible for humans to reproduce the decision of a system.
PS: "masked by: <nothing>" is classic portage bug. It's caused by a mismatch between the actual visibility filter (that selects a specific version from a list of all available versions) and the function generating the message. The latter is basically a long list of "if" statements, and the bug shows up if a version is masked by the filter, but none of the "if" clauses trigger. Which of the two is wrong then has to be determined. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
