1 |
On Wednesday 09 September 2009 13:43:13 Dale wrote: |
2 |
> Hi folks, |
3 |
> |
4 |
> Can someone tell me what this means? |
5 |
> |
6 |
> root@smoker / # emerge -p --depclean |
7 |
> |
8 |
> * Always study the list of packages to be cleaned for any obvious |
9 |
> * mistakes. Packages that are part of the world set will always |
10 |
> * be kept. They can be manually added to this set with |
11 |
> * `emerge --noreplace <atom>`. Packages that are listed in |
12 |
> * package.provided (see portage(5)) will be removed by |
13 |
> * depclean, even if they are part of the world set. |
14 |
> * |
15 |
> * As a safety measure, depclean will not remove any packages |
16 |
> * unless *all* required dependencies have been resolved. As a |
17 |
> * consequence, it is often necessary to run `emerge --update |
18 |
> * --newuse --deep @system @world` prior to depclean. |
19 |
> |
20 |
> Calculating dependencies... done! |
21 |
> |
22 |
> >>> Checking for lib consumers... |
23 |
> >>> Assigning files to packages... |
24 |
> |
25 |
> * In order to avoid breakage of link level dependencies, one or more |
26 |
> * packages will not be removed. This can be solved by rebuilding the |
27 |
> * packages that pulled them in. |
28 |
> * |
29 |
> * dev-lang/python-2.5.4-r3 pulled in by: |
30 |
> * app-office/scribus-1.3.3.11 |
31 |
> * |
32 |
> |
33 |
> >>> Adding lib providers to graph... |
34 |
> |
35 |
> \ |
36 |
> Calculating dependencies... done! |
37 |
> |
38 |
> |
39 |
> I have re-compiled scribus about three times now. I have also ran |
40 |
> python-updater a few times and it just keeps rebuilding scribus and |
41 |
> boost in a endless loop. What am I missing here? |
42 |
|
43 |
This is horrible to solve. I'll tell you what I've discovered when it happens |
44 |
to me. But first, the error message is generic and a best guess - "rebuilding |
45 |
the packages that pulled them in" might work, but also might not. |
46 |
|
47 |
The superficial problem is broken ebuilds caused by the real problem - broken |
48 |
build scripts that configure themselves in funky ways at build time. Real |
49 |
example, I have this on my machine: |
50 |
|
51 |
* dev-db/edb-9999 pulled in by: |
52 |
* media-libs/imlib2_loaders-9999 |
53 |
|
54 |
and |
55 |
|
56 |
nazgul mysql # eix imlib2_loaders |
57 |
[I] media-libs/imlib2_loaders [1] |
58 |
Installed versions: 9999(18:33:40 09/06/09)(-doc -edb -nls) |
59 |
|
60 |
and |
61 |
|
62 |
# ldd /usr/lib64/imlib2/loaders/*.so | grep edb |
63 |
libedb.so.1 => /usr/lib/libedb.so.1 (0x00007f33bf139000) |
64 |
|
65 |
So, edb is nowhere in the dependency graph for imlib2_loaders (USE=-edb). |
66 |
Portage *knows* it should not depend on edb at all. |
67 |
|
68 |
But, when imlib2_loaders builds, ./configure finds edb on the system (I have |
69 |
it, I just don't want support for it in imlib2_loaders). The ./configure is |
70 |
broken - there is no "--enable edb" in it. |
71 |
|
72 |
Now this always just happened to work just fine for all of us. Recent portage |
73 |
know records link level deps when it builds stuff (see ldd above) so now |
74 |
concludes (correctly) that imlib2_loaders does not depend on edb per portage, |
75 |
but does per the actual system. |
76 |
|
77 |
It is now clear that I now have two and only two options: |
78 |
|
79 |
- Unmerge edb. This might not be desirable and I should not be forced to do |
80 |
this. |
81 |
- Build imlib2_loaders with edb support. This also might not be desirable. |
82 |
|
83 |
Actually there's a third option: fix the e17 team's broken build scripts. |
84 |
|
85 |
In your case, I think you need to rebuild scribus with "USE=python" |
86 |
|
87 |
Note that portage can't really help you diagnose these issues, it can only |
88 |
point them out. It has no idea that the inconsistency is due to that USE flag |
89 |
(it can't read human-speak). |
90 |
|
91 |
You also can't DEPEND on scribus[python] as |
92 |
|
93 |
1. The dep is the wrong way round |
94 |
2. It's actually force USE=python for scribus if, and only if, python is |
95 |
actually already present on the system. This is also the wrong way round and |
96 |
portage should not be expected to implement funky run-time detection |
97 |
workarounds for broken ./configure scripts. |
98 |
|
99 |
I did tell you at the beginning that it was complex, right? |
100 |
|
101 |
|
102 |
-- |
103 |
alan dot mckinnon at gmail dot com |