1 |
Rich Freeman <rich0@g.o> writes: |
2 |
|
3 |
> On Sat, Sep 19, 2015 at 3:57 PM, Alan McKinnon <alan.mckinnon@×××××.com> wrote: |
4 |
>> On 19/09/2015 21:36, lee wrote: |
5 |
>>> |
6 |
>>> dev-libs/boost:0 |
7 |
>>> |
8 |
>>> (dev-libs/boost-1.56.0-r1:0/1.56.0::gentoo, ebuild scheduled for merge) pulled in by |
9 |
>>> (no parents that aren't satisfied by other packages in this slot) |
10 |
>>> |
11 |
>>> (dev-libs/boost-1.55.0-r2:0/1.55.0::gentoo, ebuild scheduled for merge) pulled in by |
12 |
>>> dev-libs/boost:0/1.55.0= required by (dev-libs/librevenge-0.0.2:0/0::gentoo, installed) |
13 |
>>> ^^^^^^^^^^ |
14 |
>>> (and 2 more with the same problem) |
15 |
>> |
16 |
>> I'm not sure why you are getting this one. Portage is only pulling in |
17 |
>> boost-1.56.0-r1 because it's the latest stable version, but librevenge |
18 |
>> requires something earlier. Portage should therefore shut up and install |
19 |
>> the only real solution - keep boost at 1.55.0 |
20 |
>> |
21 |
> |
22 |
> librevenge doesn't require an earlier version. This is either a |
23 |
> result of insufficient backtracking, or it might have to do with how |
24 |
> portage stores runtime dependencies for installed packages. |
25 |
> |
26 |
> Try adding --backtrack=50 to your command line and try again. If |
27 |
> nothing else it might simplify the output. It will take longer to |
28 |
> run. |
29 |
|
30 |
It gives the same results (after syncing again), plus a message that |
31 |
wasn't there before: |
32 |
|
33 |
|
34 |
,---- |
35 |
| x11-drivers/nvidia-drivers:0 |
36 |
| |
37 |
| (x11-drivers/nvidia-drivers-355.11:0/0::gentoo, ebuild scheduled for merge) pulled in by |
38 |
| (no parents that aren't satisfied by other packages in this slot) |
39 |
| |
40 |
| (x11-drivers/nvidia-drivers-340.93:0/0::gentoo, ebuild scheduled for merge) pulled in by |
41 |
| ~x11-drivers/nvidia-drivers-340.93 required by (media-video/nvidia-settings-340.58:0/0::gentoo, ebuild scheduled for merge) |
42 |
| ^ ^^^^^^ |
43 |
`---- |
44 |
|
45 |
|
46 |
This looks kinda weird because I expect those drivers to be updated as |
47 |
well, and if they aren't, I will have to remove nvidia-settings. |
48 |
|
49 |
Let's try backtrack 500 ... same result, and doesn't take longer. |
50 |
|
51 |
> If it is the rdepend issue then you can probably emerge -1 librevenge |
52 |
> and whatever else is depending on the old version to fix it. |
53 |
> |
54 |
> Also, emerge running --changed-deps=y from time to time may make those |
55 |
> kinds of problems less likely. The first time you do it prepare to |
56 |
> see a LOT of stuff get rebuilt - any of those packages could cause |
57 |
> issues in the future but most probably will not. |
58 |
|
59 |
Good to know, I'll keep that in mind. I tried it and it's not too much |
60 |
to rebuild, only a bit surprising: |
61 |
|
62 |
|
63 |
,---- |
64 |
| [ebuild U ] sys-devel/automake-wrapper-10 [9] |
65 |
| [ebuild R ] app-benchmarks/i7z-0.27.2 |
66 |
| [ebuild R ] net-misc/netkit-telnetd-0.17-r10 |
67 |
| [ebuild R ] virtual/editor-0 |
68 |
| [ebuild U ] sys-devel/gcc-4.8.5 [4.8.4] USE="-debug%" |
69 |
| [ebuild R ] net-dialup/ppp-2.4.7 |
70 |
| [ebuild U ] sys-apps/openrc-0.17 [0.13.11] USE="-audit%" |
71 |
| [ebuild R ] x11-terms/xterm-314 |
72 |
| [ebuild U ] net-firewall/shorewall-4.6.10.1 [4.6.6.2] |
73 |
| [ebuild NS ] sys-devel/automake-1.15 [1.11.6-r1, 1.13.4] |
74 |
| [ebuild U ] media-libs/alsa-lib-1.0.29 [1.0.28] |
75 |
| [ebuild U ] media-sound/alsa-utils-1.0.29 [1.0.28] |
76 |
| [ebuild U ] sys-apps/portage-2.2.20.1 [2.2.18] PYTHON_TARGETS="python3_4* -python3_3*" |
77 |
| [ebuild R ] app-portage/gentoolkit-0.3.0.9-r2 PYTHON_TARGETS="python3_4* -python3_3*" |
78 |
| [ebuild U ] dev-python/ssl-fetch-0.3 [0.2] PYTHON_TARGETS="python3_4* -python3_3*" |
79 |
| [ebuild U ] app-portage/mirrorselect-2.2.2-r2 [2.2.2] PYTHON_TARGETS="python3_4* -python3_3*" |
80 |
| [ebuild U ] media-gfx/gimp-2.8.14-r1 [2.8.14] USE="{-test%}" |
81 |
| [ebuild U ] media-video/mplayer-1.2_pre20150214-r1 [1.2_pre20130729] |
82 |
| [ebuild R ~] media-video/openshot-1.4.3 USE="-libav%" |
83 |
| [ebuild U ] app-editors/emacs-24.5 [24.4-r4] |
84 |
`---- |
85 |
|
86 |
|
87 |
Should I do that before updating or after? I guess I'm on the save side |
88 |
doing it before, so I'll do that. |
89 |
|
90 |
>> You fail to understand how gentoo works. At no time did Gentoo ever |
91 |
>> guarantee that updates would work like binary distros and the process |
92 |
>> would be trouble free. Quite the opposite - Gentoo is upfront in telling |
93 |
>> you that there will always be update issues and you are the person to |
94 |
>> solve them. |
95 |
>> |
96 |
> |
97 |
> While Gentoo doesn't do as much handholding as many distros, the |
98 |
> portage output above should not be viewed as something we are proud |
99 |
> of. |
100 |
|
101 |
At least I'm learning here :) |
102 |
|
103 |
> --backtrack fixes a lot of issues, and there aren't a lot of simple |
104 |
> solutions for that without slowing down emerge. |
105 |
> |
106 |
> On the other hand, a lot of the runtime dependency issues could be |
107 |
> fixed. There is a discussion on -dev right now about getting rid of |
108 |
> dynamic runtime deps, which would probably help cut down on some of |
109 |
> the more bizarre behavior. |
110 |
|
111 |
Making the output "nicer" --- i. e. more informative --- might go a long |
112 |
way towards more handholding without slowing things down. If emerge |
113 |
would tell me "you can ignore this (and look for a solution later if you |
114 |
like)" and "you need to fix this before you can proceed", I could be |
115 |
straightforward by updating and looking into fixing things that bother |
116 |
me eventually. The system would still work fine, or better than before, |
117 |
after the upgrade, which is the most important issue to begin with. |
118 |
|
119 |
The software would be updated to the best achievable point then. That's |
120 |
like getting it 95%+ perfect with 0% effort from the user, and that's |
121 |
pretty darn good. The last 5% usually take 200% of the effort. In this |
122 |
case, it's impossible to get past 96.5% because the remaining 3.5% |
123 |
inevitably must be decided by the user. And if the users didn't have |
124 |
their choices and their powers of making decisions, they'd become very |
125 |
unhappy with Gentoo. |
126 |
|
127 |
|
128 |
-- |
129 |
Again we must be afraid of speaking of daemons for fear that daemons |
130 |
might swallow us. Finally, this fear has become reasonable. |