| 1 |
Michał Górny wrote: |
| 2 |
> Consider the following: |
| 3 |
> |
| 4 |
> 1. A depends on B, both are installed, |
| 5 |
> |
| 6 |
> 2. dependency on B is removed, emerge --depclean uninstalls B thanks |
| 7 |
> to dynamic-deps, |
| 8 |
> |
| 9 |
> 3. B is treecleaned (nothing depends on it), |
| 10 |
|
| 11 |
So far I follow. |
| 12 |
|
| 13 |
|
| 14 |
> 4. old version of A is removed (user doesn't update it yet), |
| 15 |
|
| 16 |
ebuild removed from tree. |
| 17 |
|
| 18 |
|
| 19 |
> therefore dependency on B is restored from vdb. |
| 20 |
|
| 21 |
Why would removing the ebuild from the tree *add* a dependency to a |
| 22 |
system where the ebuild is installed? That doesn't seem desirable. |
| 23 |
|
| 24 |
To me it seems like a simple data model bug that vdb does not get |
| 25 |
updated to reflect the new situation after step 2 above. |
| 26 |
|
| 27 |
|
| 28 |
> So, now user has package A installed which has unsatisfied |
| 29 |
> dependency on non-available package. |
| 30 |
|
| 31 |
What is the purpose of keeping only dependencies as-they-were when |
| 32 |
the package was installed, if the package manager does not somehow |
| 33 |
benefit from that information in the future? |
| 34 |
|
| 35 |
|
| 36 |
//Peter |
Archives