1 |
On Sun, Jul 27, 2014 at 4:24 PM, Michał Górny <mgorny@g.o> wrote: |
2 |
> Dnia 2014-07-27, o godz. 10:42:19 |
3 |
> |
4 |
> Consider the following: |
5 |
> |
6 |
> 1. A depends on B, both are installed, |
7 |
> |
8 |
> 2. dependency on B is removed, emerge --depclean uninstalls B thanks |
9 |
> to dynamic-deps, |
10 |
> |
11 |
> 3. B is treecleaned (nothing depends on it), |
12 |
> |
13 |
> 4. old version of A is removed (user doesn't update it yet), therefore |
14 |
> dependency on B is restored from vdb. |
15 |
> |
16 |
> So, now user has package A installed which has unsatisfied dependency |
17 |
> on non-available package. |
18 |
|
19 |
I'd think that portage should update vdb as soon as it detects the |
20 |
dependency change. Then B would no longer depend on A in vdb. It |
21 |
shouldn't hold onto outdated information. Basically a dependency |
22 |
change should trigger a no-rebuild merge if it is safe to do so, and |
23 |
if not there should be a revbump anyway. |
24 |
|
25 |
If A is removed before there is a sync, then A is still installed on |
26 |
the user's system and portage still thinks that B depends on A, so it |
27 |
remains consistent. |
28 |
|
29 |
I acknowldege that this isn't how portage behaves today. |
30 |
|
31 |
Rich |