Lindsay Haisley posted on Wed, 19 May 2010 13:52:59 -0500 as excerpted:
> On Tue, 2010-05-18 at 19:43 -0400, Philip Webb wrote:
>> 100518 Lindsay Haisley wrote:
>> > what I have to do to resolve it?
>> >> !!! Multiple package instances within a single package slot have
>> >> been pulled !!! into the dependency graph, resulting in a slot
>> >> conflict: dev-python/gnome-vfs-python:2
>> >> ('installed', '/', 'dev-python/gnome-vfs-python-2.26.1',
>> >> 'nomerge') pulled in by
>> >> >=dev-python/gnome-vfs-python-2.26.1 required by ('installed',
>> >> >'/', 'dev-python/libgnome-python-2.26.1', 'nomerge')
>> >> (and 2 more)
>> >> ('ebuild', '/', 'dev-python/gnome-vfs-python-2.22.3', 'merge')
>> >> pulled in by
>> >> ~dev-python/gnome-vfs-python-2.22.3 required by ('installed',
>> >> '/', 'dev-python/gnome-python-2.22.3', 'nomerge') (and 2 more)
>>
>> A quick suggestion by someone who doesn't use any of these is that you
>> have incompatible versions of Libgnome-python & Gnome-python: the
>> latter is a meta-pkg & an earlier version, so try unmerging it.
>
> I'll take a look at this, but I'm looking for a broader understanding of
> this kind of message since I'm getting a number of them (this is only
> one set). What's the difference between "required by" and "pulled in
> by"? Are these message documented and explained somewhere?
I don't know that they're documented/explained anywhere formally, as the
additional verbosity is relatively new to portage. Previously, it would
have quit with far less explanation, leaving the user to work it out for
themselves what was going on. Either that, or it would have simply
upgraded, then wanted to downgrade on the next run, then wanted to upgrade
again, etc. I remember such endless upgrade/downgrade loops, and believe
me, this is better, at least providing *SOME* explanation, and preventing
the loop before it starts.
That said, as I understand it, these are in the context of the depgraph
portage is trying to construct to satisfy the new merge request, while
continuing to satisfy the requirements of existing already merged packages
as well.
In that context, "pulled in by" refers to the specific dependency as
written in the ebuild (thus the ">=" bit, the dependency is requiring a
certain version or higher), while "required by" refers to the ebuild which
contains that dependency (a specific ebuild, thus a specific package
version), that portage is evaluating while trying to resolve its depgraph
successfully, balancing what's currently installed and what is trying to
be installed.
So what it's saying:
>> >> conflict: dev-python/gnome-vfs-python:2
The name and slot of the package it's trying to resolve the conflict on.
Now the first candidate:
>> >> ('installed', '/', 'dev-python/gnome-vfs-python-2.26.1',
>> >> 'nomerge')
You currently have version gnome-vfs-python-2.26.1 installed
(currently installed, to root, package name and version, won't be merged).
(The "to root" bit you can ignore. That's there to clarify things in case
of advanced portage usage, where it may be installing to some place other
than the active system. It can be ignored in the below as well.)
>> >> pulled in by >=dev-python/gnome-vfs-python-2.26.1
The dependency that is actually pulling in that version.
It's wanting version 2.26.1 or higher (and from the "nomerge" and version
in the clause above, we see it has exactly 2.26.1, dependency currently
fulfilled)
>> >> required by ('installed', >'/',
>> >> 'dev-python/libgnome-python-2.26.1', 'nomerge')
dev-python/libgnome-python-2.26.1 is the actual ebuild containing the
above "pulled in by". It is:
(currently installed, to root, package name and version, won't be merged).
>> >> (and 2 more)
Two additional packages have a similar dependency, also met by what's
currently installed.
That's the first candidate, here's the second:
>> >> ('ebuild', '/', 'dev-python/gnome-vfs-python-2.22.3', 'merge')
It wants to install version 2.22.3
(ebuild so not yet installed, to root, package name and version, would be
merged)
>> >> pulled in by ~dev-python/gnome-vfs-python-2.22.3
The actual dependency trying to pull it in. Here we see the dependency
wants (upstream) version 2.22.3 specifically, except that all (gentoo) -rX
revisions of said upstream version are allowed (that's what the ~ means).
(And from the "merge" and version named in the clause above it, we see
this dependency is NOT currently fullfilled, as it wants to merge it.)
>> >> required by ('installed', '/',
>> >> 'dev-python/gnome-python-2.22.3', 'nomerge')
dev-python/gnome-python-2.22.3 is the actual ebuild containing the above
"pulled in by". It is:
(currently installed, to root, package name and version, won't be merged)
>> >> (and 2 more)
Again, two additional packages have a similar dependency, also currently
unmet by what's currently installed.
The conflict is that both 2.22.3 and 2.26.1 are in slot 2, and can't be
installed together, yet one dependency is for >=2.26.1, thus eliminating
2.22.3, while the other is for 2.22.3 specifically, thus eliminating
2.26.1.
Note that both of these are requirements of currently installed (nomerge)
packages, so the conflict must be new -- the dependencies on one or the
other of the packages apparently changed since one or the other was
installed. Probably, someone noticed a problem, filed a bug, and the
resolution was to tighten up the dependencies so the two sets of packages
couldn't be installed together. As with Philip, I don't have these
packages installed here (I'm a kde guy, preferring to keep gnome as far
from my system as possible, upstream kde4 has enough problems to deal
with, tho the gentoo/kde guys do a great job with what upstream gives
them), but his suggestion that gnome-python is an earlier virtual package
no longer needed, does seem consistent with the facts as I see them here
-- it IS an earlier version, 2.22.3, while you're working with 2.26.1, now
(that assumes the version numbers are related, which they seem to be).
A hint, take it or leave it at your option. This sort of problem is going
to be more frequent and more confusing to resolve when it occurs if you
don't both keep your system fully updated (not just leaves, but adding
--deep to your --update), and regularly remove cruft (using --newuse with
your updates as well, then doing revdep-rebuild and emerge --depclean).
In particular, it's my guess that this apparently outdated virtual,
gnome-python, would have been removed as unneeded along with other
existing 2.22.3 packages when 2.26 was installed, had you been regularly
running emerge --depclean, since removing package no longer required by
stuff in @system and @world is what it /does/. Then you'd have not gotten
to this point, since the straggly bits of 2.22.3 would have been removed
with the --depclean after 2.26 was installed, so portage would have never
been trying to satisfy dependencies with packages from both installed at
the same time.
Of course, to safely run --depclean, you have to have been keeping up with
your --newuse and revdep-rebuilds. Additionally, if you haven't been
running it routinely, there will probably be a number of packages in the
first --depclean --pretend run (you DO run emerge with --ask or --pretend
first, right?) that you actually want to keep, and should add to your
world file using emerge --select --noreplace, before running --depclean
for real, without the --pretend, or going ahead with --ask.
The --update --deep simply tells portage to consider deep dependencies for
update as well as stuff in the world file. This will mean a few more
library and etc updates before absolutely necessary, but by keeping
current with them, it'll also mean fewer headaches when they ARE updated,
because the version gaps between updates will be smaller. The tradeoff is
more merging that the computer can handle itself, for less problems where
it can't handle it automatically and needs your help to resolve a problem.
Of course, the other thing is not to let a system get too outdated between
syncs and updates. From my observations both in my own use and from the
comments of others, it seems that once a month updates are probably as
long as you can go between them, without starting to have additional
problems because the updates get so large they are difficult to handle and
to pin down problems when they do occur. I've seen others say they have
that problem if they let the gap between updates grow to more than once a
week, but these guys are obviously used to smaller updates in the first
place. Certainly, tho, I'd say if you're letting it grow to two months or
more between updates, you're just making more headaches for yourself when
you /do/ update, as the updates aren't likely to go as smoothly, both
because of the number of them, and because the version jumps will be
higher. And, pinning down problems when you do have them, gets much
harder with more updates and bigger gaps, as well.
So for Gentoo, I'd recommend updates at least once a month (consider once
a week if you can), with --deep --newuse, and consistently running
revdep-rebuild and emerge --depclean afterward (with the caveat about the
first time you depclean in awhile as mentioned above). There will still
be the occasional issue like the one you mentioned, but they'll be far
fewer between, and when they happen, others will be seeing them too, so
it'll be far easier to get help in fixing them if needed.
But of course, it's your system not mine, and if that doesn't fit your
style, feel free to do it as you like. That's what's nice about Gentoo,
it gives you a lot of flexibility in that regard. =:^)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
