Tom Wijsman <tom...@gentoo.org> wrote: > > Useless triggers are the problem; why are the rev bumps needed, why are > dependencies forgotten, ...?
It is not only about *forgotten* dependencies: It is whenever something is restructured, a new project appears, etc. Some examples: 1. Package foo/bar splits into foo/bar-base and foo/bar-gui. Should all the packages depending on foo/bar be recompiled, just because the dependency must be relaxed? 2. Package foo/bar-base and foo/bar-gui merge to foo/bar. In this case the dependency needs to be strengthened, but technically a recompile should not be necessary (perhaps there are exceptions where it is necessary for newer versions, but these should be rare; in any case, the developer should know what is "correct"). 3. Package foo/bar was forked to foo/baz, both providing the same ABI. Maybe a new virtual is introduced in gentoo, or maybe the alternative dependency should be directly added in all ebuilds. Absolutely no reason to force a rebuild, but with static dependencies and without a bump, the user is not able to change to the new foo/baz. 4. Package foo/bar was forked to foo/baz, both providing the same API but not the same ABI. This is a problematic situation, but it is so with and without dynamic/static dependencies: Even if a user once reemerges a package depending on it, he may nevertheless later replace foo/bar by foo/baz and gets a broken system despite all dependencies are satisfied all of the time. Actually, 4. is an example why subslotting can *never* fully replace revdep-rebuild. Although 4. touches also a different problem, actually the triggering of a rebuild in case 4., just because a new alternative is available, is completely useless. (*If* one wants to fix 4., one must introduce an extended dependency syntax, and this would have problems with virtuals etc.) Probably there are many more examples than 1.-4, but I hope that the point becomes clear: Whenever packages split, merge, or can substitute each other, dependency changes are necessary, and rebuilds caused by these are unnecessary. Unfortunately, such things happen *very* frequently... Nobody is to blame for this; the PM just should be ready to deal with such situations without unnecessary rebuilds, be it by dynamic deps or by a mechanism to avoid recompilation.
