On Wednesday 09 September 2009 13:43:13 Dale wrote:
> Hi folks,
>
> Can someone tell me what this means?
>
> r...@smoker / # emerge -p --depclean
>
> * Always study the list of packages to be cleaned for any obvious
> * mistakes. Packages that are part of the world set will always
> * be kept. They can be manually added to this set with
> * `emerge --noreplace <atom>`. Packages that are listed in
> * package.provided (see portage(5)) will be removed by
> * depclean, even if they are part of the world set.
> *
> * As a safety measure, depclean will not remove any packages
> * unless *all* required dependencies have been resolved. As a
> * consequence, it is often necessary to run `emerge --update
> * --newuse --deep @system @world` prior to depclean.
>
> Calculating dependencies... done!
>
> >>> Checking for lib consumers...
> >>> Assigning files to packages...
>
> * In order to avoid breakage of link level dependencies, one or more
> * packages will not be removed. This can be solved by rebuilding the
> * packages that pulled them in.
> *
> * dev-lang/python-2.5.4-r3 pulled in by:
> * app-office/scribus-1.3.3.11
> *
>
> >>> Adding lib providers to graph...
>
> \
> Calculating dependencies... done!
>
>
> I have re-compiled scribus about three times now. I have also ran
> python-updater a few times and it just keeps rebuilding scribus and
> boost in a endless loop. What am I missing here?
This is horrible to solve. I'll tell you what I've discovered when it happens
to me. But first, the error message is generic and a best guess - "rebuilding
the packages that pulled them in" might work, but also might not.
The superficial problem is broken ebuilds caused by the real problem - broken
build scripts that configure themselves in funky ways at build time. Real
example, I have this on my machine:
* dev-db/edb-9999 pulled in by:
* media-libs/imlib2_loaders-9999
and
nazgul mysql # eix imlib2_loaders
[I] media-libs/imlib2_loaders [1]
Installed versions: 9999(18:33:40 09/06/09)(-doc -edb -nls)
and
# ldd /usr/lib64/imlib2/loaders/*.so | grep edb
libedb.so.1 => /usr/lib/libedb.so.1 (0x00007f33bf139000)
So, edb is nowhere in the dependency graph for imlib2_loaders (USE=-edb).
Portage *knows* it should not depend on edb at all.
But, when imlib2_loaders builds, ./configure finds edb on the system (I have
it, I just don't want support for it in imlib2_loaders). The ./configure is
broken - there is no "--enable edb" in it.
Now this always just happened to work just fine for all of us. Recent portage
know records link level deps when it builds stuff (see ldd above) so now
concludes (correctly) that imlib2_loaders does not depend on edb per portage,
but does per the actual system.
It is now clear that I now have two and only two options:
- Unmerge edb. This might not be desirable and I should not be forced to do
this.
- Build imlib2_loaders with edb support. This also might not be desirable.
Actually there's a third option: fix the e17 team's broken build scripts.
In your case, I think you need to rebuild scribus with "USE=python"
Note that portage can't really help you diagnose these issues, it can only
point them out. It has no idea that the inconsistency is due to that USE flag
(it can't read human-speak).
You also can't DEPEND on scribus[python] as
1. The dep is the wrong way round
2. It's actually force USE=python for scribus if, and only if, python is
actually already present on the system. This is also the wrong way round and
portage should not be expected to implement funky run-time detection
workarounds for broken ./configure scripts.
I did tell you at the beginning that it was complex, right?
--
alan dot mckinnon at gmail dot com
