| 1 |
Tom Wijsman <TomWij@g.o> wrote: |
| 2 |
> |
| 3 |
> Useless triggers are the problem; why are the rev bumps needed, why are |
| 4 |
> dependencies forgotten, ...? |
| 5 |
|
| 6 |
It is not only about *forgotten* dependencies: |
| 7 |
It is whenever something is restructured, a new project appears, etc. |
| 8 |
|
| 9 |
Some examples: |
| 10 |
|
| 11 |
1. Package foo/bar splits into foo/bar-base and foo/bar-gui. |
| 12 |
Should all the packages depending on foo/bar be recompiled, |
| 13 |
just because the dependency must be relaxed? |
| 14 |
|
| 15 |
2. Package foo/bar-base and foo/bar-gui merge to foo/bar. |
| 16 |
In this case the dependency needs to be strengthened, |
| 17 |
but technically a recompile should not be necessary |
| 18 |
(perhaps there are exceptions where it is necessary for |
| 19 |
newer versions, but these should be rare; in any case, |
| 20 |
the developer should know what is "correct"). |
| 21 |
|
| 22 |
3. Package foo/bar was forked to foo/baz, both providing |
| 23 |
the same ABI. Maybe a new virtual is introduced in gentoo, |
| 24 |
or maybe the alternative dependency should be directly |
| 25 |
added in all ebuilds. |
| 26 |
Absolutely no reason to force a rebuild, but with static |
| 27 |
dependencies and without a bump, the user is not able |
| 28 |
to change to the new foo/baz. |
| 29 |
|
| 30 |
4. Package foo/bar was forked to foo/baz, both providing |
| 31 |
the same API but not the same ABI. |
| 32 |
This is a problematic situation, but it is so with and |
| 33 |
without dynamic/static dependencies: Even if a user once |
| 34 |
reemerges a package depending on it, he may nevertheless later |
| 35 |
replace foo/bar by foo/baz and gets a broken system |
| 36 |
despite all dependencies are satisfied all of the time. |
| 37 |
|
| 38 |
Actually, 4. is an example why subslotting can *never* |
| 39 |
fully replace revdep-rebuild. |
| 40 |
|
| 41 |
Although 4. touches also a different problem, actually |
| 42 |
the triggering of a rebuild in case 4., just because |
| 43 |
a new alternative is available, is completely useless. |
| 44 |
(*If* one wants to fix 4., one must introduce an |
| 45 |
extended dependency syntax, and this would have problems |
| 46 |
with virtuals etc.) |
| 47 |
|
| 48 |
Probably there are many more examples than 1.-4, but I hope |
| 49 |
that the point becomes clear: Whenever packages split, merge, |
| 50 |
or can substitute each other, dependency changes are necessary, |
| 51 |
and rebuilds caused by these are unnecessary. |
| 52 |
|
| 53 |
Unfortunately, such things happen *very* frequently... |
| 54 |
|
| 55 |
Nobody is to blame for this; the PM just should be ready |
| 56 |
to deal with such situations without unnecessary rebuilds, |
| 57 |
be it by dynamic deps or by a mechanism to avoid |
| 58 |
recompilation. |
Archives