| 1 |
One of the recurring problems we face in #gentoo is end users coming |
| 2 |
to us with confusing problems, and their problems are exacerbated |
| 3 |
because their default workflow ended up with them unmasking some ** |
| 4 |
version of perl. |
| 5 |
|
| 6 |
There is already a bug for this behaviour [1], and comments say that |
| 7 |
portage doing this is "a bug", but the situations which it occurs in |
| 8 |
are hard to diagnose what the "real problem" is. |
| 9 |
|
| 10 |
Much of the time, what has occurred is there was some other problem, |
| 11 |
and portage bodged its way around the real problem by choosing a |
| 12 |
solution that should be considered unacceptable, instead of presenting |
| 13 |
the real problem. |
| 14 |
|
| 15 |
Some of the time, the cause is as simple as a single package being |
| 16 |
installed that isn't in the @world dependency graph any more, which is |
| 17 |
tripping up portage slot-rebuild behaviour. |
| 18 |
|
| 19 |
In practice, what this currently means is that stable users end up |
| 20 |
installing *developmental/experimental* packages that exist only for |
| 21 |
experts and gentoo maintainers, and this is an unacceptable resolution. |
| 22 |
|
| 23 |
If this behaviour was being triggered by anything other than portage's |
| 24 |
dependency resolver failing, it would be considered a serious QA |
| 25 |
violation. |
| 26 |
|
| 27 |
Its understood that portage maintainers want to "fix" this behaviour so |
| 28 |
the problem doesn't occur, but until that can be done, the present |
| 29 |
default behaviour is actively harmful, and I suggest it be disabled by |
| 30 |
default until it can be guaranteed to give the right results. |
| 31 |
|
| 32 |
1: https://bugs.gentoo.org/658648 |
Archives