| 1 |
Mike Gilbert <floppym <at> gentoo.org> writes: |
| 2 |
|
| 3 |
|
| 4 |
> Basically, yes. If [R]DEPEND in /var/db/pkg is different from the |
| 5 |
> values in the ebuilds in the tree, <at> changed-deps will select it. |
| 6 |
|
| 7 |
> > Also, these two similar commands return different results (I have |
| 8 |
> > bdeps=y in DEFAULT_OPTS btw): |
| 9 |
> > |
| 10 |
> > emerge -uND --changed-deps=y world (51 packages) |
| 11 |
> > emerge <at> changed-deps (11 packages) |
| 12 |
|
| 13 |
> > Do you know why those commands give different results? |
| 14 |
> > The smaller list is a strict subset of the longer one. |
| 15 |
|
| 16 |
> That difference is surprising; you would probably need to ask the |
| 17 |
> portage developers to get a real answer. |
| 18 |
|
| 19 |
|
| 20 |
I do not "own' the code underneath these options, nor would I waste my |
| 21 |
time on what is undoubtedly broken logic. Portage and associated tools do |
| 22 |
not have a complete description of the problem with the current VDB. A DAG |
| 23 |
is the best way to solve the problem of these portage anomalies. |
| 24 |
|
| 25 |
Or just rebuild @world and occasionally @system, and then cobble together |
| 26 |
a script that hopefully finds all the other installed codes and packages.... |
| 27 |
Still, cruft (some of the old files that should have been removed at some |
| 28 |
point) remains. |
| 29 |
|
| 30 |
I certainly and not saying this is an easy problem to solve; all distros |
| 31 |
suffer tremendously here. That's why many just 'reinstall' periodically. |
| 32 |
But without a robust implementation of a DAG or something similar, deep |
| 33 |
problems will remain unresolved and hopefully, not noticed. Many large data |
| 34 |
centers just 'reload' entire rows of racked systems too. |
| 35 |
|
| 36 |
These are big problems on clusters/clouds. The current approach is to build |
| 37 |
many 'customized frameworks' for different classes of problems, on top of |
| 38 |
poorly implemented distros with a collection of packages. That approach |
| 39 |
works well, if the packages are relegated to one complex language and |
| 40 |
scripts. Once a collection of codes, a package if you like, requires several |
| 41 |
complex programming languages to compile and execute, thus crossing |
| 42 |
framework boundaries, then the problems exponentiate, and it becomes |
| 43 |
an admin/security mess. I do believe that the current gentoo approach is |
| 44 |
going to be robustly application as a pristine solution for this gargantuan |
| 45 |
cluster problem; but a DAG sort of fundamental tooling is going to be |
| 46 |
minimally sufficient if stability is to be achieved. Clusters are already |
| 47 |
making their way to gentoo so these problem in only going to grow. |
| 48 |
|
| 49 |
|
| 50 |
Oddly enough, I feel like and uneducated admin in these matters. But, I do |
| 51 |
now have several major corps that want me to be a temporary consultant |
| 52 |
on cluster problems. We shall see. We shall see what's what. |
| 53 |
|
| 54 |
|
| 55 |
wwr, |
| 56 |
James |
Archives