On 26/09/2015 11:47, lee wrote:
> Rich Freeman <ri...@gentoo.org> writes:
>
>> On Sat, Sep 19, 2015 at 3:57 PM, Alan McKinnon <alan.mckin...@gmail.com>
>> wrote:
>>> On 19/09/2015 21:36, lee wrote:
>>>>
>>>> dev-libs/boost:0
>>>>
>>>> (dev-libs/boost-1.56.0-r1:0/1.56.0::gentoo, ebuild scheduled for merge)
>>>> pulled in by
>>>> (no parents that aren't satisfied by other packages in this slot)
>>>>
>>>> (dev-libs/boost-1.55.0-r2:0/1.55.0::gentoo, ebuild scheduled for merge)
>>>> pulled in by
>>>> dev-libs/boost:0/1.55.0= required by
>>>> (dev-libs/librevenge-0.0.2:0/0::gentoo, installed)
>>>> ^^^^^^^^^^
>>>> (and 2 more with the same problem)
>>>
>>> I'm not sure why you are getting this one. Portage is only pulling in
>>> boost-1.56.0-r1 because it's the latest stable version, but librevenge
>>> requires something earlier. Portage should therefore shut up and install
>>> the only real solution - keep boost at 1.55.0
>>>
>>
>> librevenge doesn't require an earlier version. This is either a
>> result of insufficient backtracking, or it might have to do with how
>> portage stores runtime dependencies for installed packages.
>>
>> Try adding --backtrack=50 to your command line and try again. If
>> nothing else it might simplify the output. It will take longer to
>> run.
>
> It gives the same results (after syncing again), plus a message that
> wasn't there before:
>
>
> ,----
> | x11-drivers/nvidia-drivers:0
> |
> | (x11-drivers/nvidia-drivers-355.11:0/0::gentoo, ebuild scheduled for
> merge) pulled in by
> | (no parents that aren't satisfied by other packages in this slot)
> |
> | (x11-drivers/nvidia-drivers-340.93:0/0::gentoo, ebuild scheduled for
> merge) pulled in by
> | ~x11-drivers/nvidia-drivers-340.93 required by
> (media-video/nvidia-settings-340.58:0/0::gentoo, ebuild scheduled for merge)
> | ^ ^^^^^^
> `----
>
>
> This looks kinda weird because I expect those drivers to be updated as
> well, and if they aren't, I will have to remove nvidia-settings.
>
> Let's try backtrack 500 ... same result, and doesn't take longer.
That doesn't look like a block. It looks like an info message that
portage is "helpfully" displaying (but really belongs only in -v output.
Maybe even the non-existent -vvv...)
Portage is telling you *why* it is not updating to latest stable
nvidia-drivers even though a higher version is in the tree. It's because
nvidia-settings is out of step with nvidia-drivers. Look at output of
"eix nvidia":
nvidia-drivers-355.11 is stable
nvidia-settings-355.11 is unstable.
The driver package will update to 355.11 when the settings package goes
stable.
A related question is "do you really need the latest nvidia drivers, or
is 340.93 still good enough? It was good enough for the entire time you
had it installed."
>
>> If it is the rdepend issue then you can probably emerge -1 librevenge
>> and whatever else is depending on the old version to fix it.
>>
>> Also, emerge running --changed-deps=y from time to time may make those
>> kinds of problems less likely. The first time you do it prepare to
>> see a LOT of stuff get rebuilt - any of those packages could cause
>> issues in the future but most probably will not.
>
> Good to know, I'll keep that in mind. I tried it and it's not too much
> to rebuild, only a bit surprising:
>
>
> ,----
> | [ebuild U ] sys-devel/automake-wrapper-10 [9]
> | [ebuild R ] app-benchmarks/i7z-0.27.2
> | [ebuild R ] net-misc/netkit-telnetd-0.17-r10
> | [ebuild R ] virtual/editor-0
> | [ebuild U ] sys-devel/gcc-4.8.5 [4.8.4] USE="-debug%"
> | [ebuild R ] net-dialup/ppp-2.4.7
> | [ebuild U ] sys-apps/openrc-0.17 [0.13.11] USE="-audit%"
> | [ebuild R ] x11-terms/xterm-314
> | [ebuild U ] net-firewall/shorewall-4.6.10.1 [4.6.6.2]
> | [ebuild NS ] sys-devel/automake-1.15 [1.11.6-r1, 1.13.4]
> | [ebuild U ] media-libs/alsa-lib-1.0.29 [1.0.28]
> | [ebuild U ] media-sound/alsa-utils-1.0.29 [1.0.28]
> | [ebuild U ] sys-apps/portage-2.2.20.1 [2.2.18]
> PYTHON_TARGETS="python3_4* -python3_3*"
> | [ebuild R ] app-portage/gentoolkit-0.3.0.9-r2
> PYTHON_TARGETS="python3_4* -python3_3*"
> | [ebuild U ] dev-python/ssl-fetch-0.3 [0.2] PYTHON_TARGETS="python3_4*
> -python3_3*"
> | [ebuild U ] app-portage/mirrorselect-2.2.2-r2 [2.2.2]
> PYTHON_TARGETS="python3_4* -python3_3*"
> | [ebuild U ] media-gfx/gimp-2.8.14-r1 [2.8.14] USE="{-test%}"
> | [ebuild U ] media-video/mplayer-1.2_pre20150214-r1 [1.2_pre20130729]
> | [ebuild R ~] media-video/openshot-1.4.3 USE="-libav%"
> | [ebuild U ] app-editors/emacs-24.5 [24.4-r4]
> `----
>
>
> Should I do that before updating or after? I guess I'm on the save side
> doing it before, so I'll do that.
Before, or just include the option in your emerge command. Portage will
sort out the order to build them in.
Remember something about portage - the only source of info it has about
packages is what is in ebuilds. So if say a package from upstream now
needs a different version of automake to build correctly, and the dev
forgot to add that[1], portage can't take account of it and can't help.
Portage also has many useful shortcuts, things like "you don't need to
rebuild that package just yet as nothing in the current list needs it
yet" so there are options to leave those packages out. But if "nothing
needs it yet" is not true because it's missing from ebuilds, you run
into a mess.
And the really important thing is, portage cannot help resolve this.
It's dumb software and has no clue why that build is failing.
>
>>> You fail to understand how gentoo works. At no time did Gentoo ever
>>> guarantee that updates would work like binary distros and the process
>>> would be trouble free. Quite the opposite - Gentoo is upfront in telling
>>> you that there will always be update issues and you are the person to
>>> solve them.
>>>
>>
>> While Gentoo doesn't do as much handholding as many distros, the
>> portage output above should not be viewed as something we are proud
>> of.
>
> At least I'm learning here :)
Good for you. Learning is always hard.
Success has a small learning potential; failure has huge learning
potential. And with computing the most valuable lesson is often what not
to do.
>
>> --backtrack fixes a lot of issues, and there aren't a lot of simple
>> solutions for that without slowing down emerge.
>>
>> On the other hand, a lot of the runtime dependency issues could be
>> fixed. There is a discussion on -dev right now about getting rid of
>> dynamic runtime deps, which would probably help cut down on some of
>> the more bizarre behavior.
>
> Making the output "nicer" --- i. e. more informative --- might go a long
> way towards more handholding without slowing things down. If emerge
> would tell me "you can ignore this (and look for a solution later if you
> like)" and "you need to fix this before you can proceed", I could be
> straightforward by updating and looking into fixing things that bother
> me eventually. The system would still work fine, or better than before,
> after the upgrade, which is the most important issue to begin with.
There's a huge problem with that.
Seems to me you are thinking like a human (because you are one) and not
seeing portage's limits. Portage has no idea what would solve the issue
so can't give any recommendations worth a damn. The best it can do is
print some hardcoded logic that looks like it might apply.
For instance, say you have two packages A and B, and both have USE flag
Z. On your system you have A build with Z and B built without Z. After a
sync, the latest ebuild for A says that is Z is enabled, then it
requires Z also be enabled in B.
Portage is not going to just change your USE preferences so it tells you
"dude, you need to disable Z for A, or enable it for B. I can't continue
till you fix that". Portage can tell you this because the data fits a
standard pattern.
Ah, but those things are rare. The real world we live in is much more
complicated than the exact thing in your PC's RAM - problems are more
like cyclic deps that conflict, and portage does not know what you want.
Instead it just dumps a crap load of related output and tells you to
figure it out, because it can't.
Binary distros get around this problem by removing your choice, so the
problem never happens there.
>
> The software would be updated to the best achievable point then.
Err, that's exactly what portage already does. In the absence of errors,
it updates what it can. Some errors are considered serious enough, with
enough possible side-effects, that portage will not continue with a full
update till you fix them. You can often get around this by emerging
individual packages instead of everything using world
> That's
> like getting it 95%+ perfect with 0% effort from the user, and that's
> pretty darn good. The last 5% usually take 200% of the effort. In this
> case, it's impossible to get past 96.5% because the remaining 3.5%
> inevitably must be decided by the user. And if the users didn't have
> their choices and their powers of making decisions, they'd become very
> unhappy with Gentoo.
Again, that's exactly what portage does. Perhaps you don't see it yet
because portage doesn't pretty-print it's output much.
It's been said many times in this thread - the output could be more
useful. What usually goes unsaid is that doing that is insanely,
amazingly, frickingly HARD. The devs are improving portage all the time,
and I'm confident they will improve output when they know how to. Right
now, they probably don't, it's still a question without an answer.
If you know how to improve it, the devs will happily accept high-quality
patches.
[1] This is a very easy mistake to make. The dev can easily already have
the new version of automake so stuff just works for him.
--
Alan McKinnon
alan.mckin...@gmail.com
