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
