1 |
----- Zac Medico <zmedico@g.o> a écrit : |
2 |
|
3 |
> > The goal of my tool is to have correct manipulation of package dependencies, and in particular here, I focus on the packages that are installed but not in the portage tree/a local overlay anymore (the problem does not occur for other packages). |
4 |
> > It seems that installed packages do not store which are the actual cpv they depend on. Correct? |
5 |
> |
6 |
> Right, because unfortunately that's something that changes over time. |
7 |
> |
8 |
> Also, we may not be able to pin it down at any given moment if we have |
9 |
> inconsistent || preferences as described here: |
10 |
> |
11 |
> https://archives.gentoo.org/gentoo-dev/message/550d3859dea6d0fb0b39064628992634 |
12 |
|
13 |
Hmm, I think I see what you mean. |
14 |
Storing the cpvs that was used during solving the package's dependencies would be too restrictive, since two different packages could provide the exact same functionalities/libraries. |
15 |
And so, during a system update, only looking at the cpv dependencies would trigger useless recompilation of the packages that depend on the updated packages. |
16 |
Correct? |
17 |
|
18 |
Btw, my tool's solver does not have the problem discussed in the thread you're mentioning: atom order in lists has no influence in my solver. |
19 |
Would fixing the inconsistent || preferences make storing cpvs for installed packages more realistic? |
20 |
|
21 |
|
22 |
> > Also, I wanted to use the ebuild tool to install/uninstall package, which is not possible with this solution apparently. |
23 |
> |
24 |
> Why not? Would the preserve-libs feature solve your problem? |
25 |
|
26 |
... I'm sorry, I wasn't aware of this feature. |
27 |
It would definitively solve the issue (except, as described in the bug 459038, when external tools remove libs). |
28 |
|
29 |
This discussion is very interesting! |
30 |
If I take this double layer of dependencies, I have to check how this influences the theory underlying my tool. |
31 |
|
32 |
However, I still doubt that only storing the soname dependencies is enough. |
33 |
Consider package A (that cannot be recompiled) that depends on package B which provides lib L.so. |
34 |
B is recompiled with different use flags, which put different functionalities in L.so. |
35 |
The dependencies of A are still satisfied (B is installed, L.so is available), but since the content of L.so changed, A cannot execute anymore. |
36 |
Hypothetically, can this scenario occur? |
37 |
Can this scenario occur in practice? |
38 |
Is there a way in emerge/portage to avoid it? |
39 |
|
40 |
|
41 |
> Well, there are a lot of upgrades that can't be performed without |
42 |
> temporarily breaking something, so the "forbid broken dependencies" idea |
43 |
> doesn't sound feasible to me. |
44 |
|
45 |
Could you tell me about several instances of such needed dependency breakage? |
46 |
You have far more experience than me on this, and it would be nice for me to know what I'm up against. |
47 |
|
48 |
Many thanks! |
49 |
Michael |