Re: [gentoo-user] --depclean and python needed by scribus.

[Alan McKinnon <alan.mckinnon@gmail.com>]

On Wednesday 09 September 2009 13:43:13 Dale wrote:
> Hi folks,
> 
> Can someone tell me what this means?
> 
> root@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