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.
> 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.
>> 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 :)
> --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.
The software would be updated to the best achievable point then. 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 we must be afraid of speaking of daemons for fear that daemons
might swallow us. Finally, this fear has become reasonable.
