[gentoo-user] Re: dynamic deps, wtf are they exactly

[James <wireless@tampabay.rr.com>]

Mike Gilbert <floppym <at> gentoo.org> writes:


> Basically, yes. If [R]DEPEND in /var/db/pkg is different from the
> values in the ebuilds in the tree,  <at> changed-deps will select it.

> > Also, these two similar commands return different results (I have
> > bdeps=y in DEFAULT_OPTS btw):
> >
> > emerge -uND --changed-deps=y world         (51 packages)
> > emerge  <at> changed-deps                       (11 packages)

> > Do you know why those commands give different results?
> > The smaller list is a strict subset of the longer one.

> That difference is surprising; you would probably need to ask the
> portage developers to get a real answer.


I do not "own' the code underneath these options, nor would I waste my
time on what is undoubtedly broken logic. Portage and associated tools do
not have a complete description of the problem with  the current VDB. A DAG
is the best way to solve the problem of these portage anomalies. 

Or just rebuild @world  and occasionally @system, and then cobble together
a script that hopefully finds all the other installed codes and packages....
Still, cruft (some of the old files that should have been removed at some
point) remains.

I certainly and not saying this is an easy problem to solve; all distros
suffer tremendously here. That's why many just 'reinstall' periodically.
But without a robust implementation of a DAG or something similar, deep
problems will remain unresolved and hopefully, not noticed. Many large data
centers just 'reload' entire rows of racked systems too.

These are big problems on clusters/clouds. The current approach is to build
many 'customized frameworks' for different classes of problems, on top of 
poorly implemented distros with a collection of packages. That approach
works well, if the packages are relegated to one complex language and
scripts. Once a collection of codes, a package if you like, requires several
complex programming languages to compile and execute, thus crossing
framework boundaries, then the problems exponentiate, and it becomes
an admin/security mess. I do believe that the current gentoo approach is
going to be robustly application as a pristine solution for this gargantuan
cluster problem; but a DAG sort of fundamental tooling is going to be
minimally sufficient if  stability is to be achieved.  Clusters are already
making their way to gentoo so these problem in only going to grow.


Oddly enough, I feel like and uneducated  admin in these matters. But, I do
now have several major corps that want me to be a temporary consultant
on cluster problems.   We shall see. We shall see what's what.


wwr,
James