Re: [gentoo-dev] Portage dependency solving algorithm

[Zac Medico]

On 11/19/2014 11:59 AM, Andrew Savchenko wrote:
> Hello,
>
> On Mon, 17 Nov 2014 21:55:48 -0800 Zac Medico wrote:
>> On 11/17/2014 09:47 PM, Andrew Savchenko wrote:
>>> I use 2.2.14 on both hosts (and usually latest ~x86 portage is
>>> there). I thought that running fixpackages should be enough to run
>>> emerge with --dynamic-deps=n.
>>
>> It depends on how badly the installed deps have diverged from the
>> corresponding ebuilds in the tree.
>
> I tried fixpackages. It fixed some problems and looks like
> dependencies resolution became faster. But not all problems are
> fixed and I can't use --dynamic-deps n on both systems for now;
> and emerge @changed-deps fails due to numerous conflicts, blocks,
> unsatisfied deps (this is not surprising, since it doesn't try to
> update all packages in tree).
>
> By the way, is there any way to unroll conflict lists in portage
> output? I mean if I have following:
>
>   (dev-lang/ghc-7.6.3-r1:0/7.6.3::gentoo, installed) pulled in by
>     >=dev-lang/ghc-6.8.2:0/7.6.3= required by (dev-haskell/random-1.0.1.1-r1:0/1.0.1.1::gentoo, installed)
> 			^^^^^^^^^
>     (and 68 more with the same problem)
>
> How can I see all list of these 68 packages? Sometimes this feature is
> really desired, e.g. if I don't want to update all @world but need to
> apply GLSA fix which leads to similar conflicts. I can't find any
> switch in emerge manual.

There's currently no switch for this. However, you can use a a command
like this to see all installed packages that pull in your installed ghc:

	emerge -pv --depclean dev-lang/ghc

I've filed a feature request bug for the switch that you have requested:

	https://bugs.gentoo.org/show_bug.cgi?id=529988

> As for hitomi box, it is both slower and have much older packages,
> so I'm still struggling to fix conflicts and other issues. Results
> will be available later.

From your results, it seems that _select_pkg_highest_available would be
an obvious thing to optimize. This method already uses memoization, but
the cache is entirely discarded each time that a package is added to the
graph. I will see about making it salvage as much cache as possible when
a package is added.

> P.S. Note for those who would like to use gpro2dot: it should be
> run with the same python interpreter active as was used during
> pstats data collection, otherwise it will fail to process data.
> I spent some time while figuring this out.

I wasn't aware of that, so thanks for the tip.
-- 
Thanks,
Zac