[gentoo-desktop] Re: I need an explanation

[Duncan]

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