1 |
On Tue, Mar 24, 2020 at 11:31 AM <michael.lienhardt@×××××××.net> wrote: |
2 |
|
3 |
> |
4 |
> ----- Zac Medico <zmedico@g.o> a écrit : |
5 |
> |
6 |
> > > The goal of my tool is to have correct manipulation of package |
7 |
> dependencies, and in particular here, I focus on the packages that are |
8 |
> installed but not in the portage tree/a local overlay anymore (the problem |
9 |
> does not occur for other packages). |
10 |
> > > It seems that installed packages do not store which are the actual cpv |
11 |
> they depend on. Correct? |
12 |
> > |
13 |
> > Right, because unfortunately that's something that changes over time. |
14 |
> > |
15 |
> > Also, we may not be able to pin it down at any given moment if we have |
16 |
> > inconsistent || preferences as described here: |
17 |
> > |
18 |
> > |
19 |
> https://archives.gentoo.org/gentoo-dev/message/550d3859dea6d0fb0b39064628992634 |
20 |
> |
21 |
> Hmm, I think I see what you mean. |
22 |
> Storing the cpvs that was used during solving the package's dependencies |
23 |
> would be too restrictive, since two different packages could provide the |
24 |
> exact same functionalities/libraries. |
25 |
> And so, during a system update, only looking at the cpv dependencies would |
26 |
> trigger useless recompilation of the packages that depend on the updated |
27 |
> packages. |
28 |
> Correct? |
29 |
> |
30 |
> Btw, my tool's solver does not have the problem discussed in the thread |
31 |
> you're mentioning: atom order in lists has no influence in my solver. |
32 |
> Would fixing the inconsistent || preferences make storing cpvs for |
33 |
> installed packages more realistic? |
34 |
> |
35 |
> |
36 |
> > > Also, I wanted to use the ebuild tool to install/uninstall package, |
37 |
> which is not possible with this solution apparently. |
38 |
> > |
39 |
> > Why not? Would the preserve-libs feature solve your problem? |
40 |
> |
41 |
> ... I'm sorry, I wasn't aware of this feature. |
42 |
> It would definitively solve the issue (except, as described in the bug |
43 |
> 459038, when external tools remove libs). |
44 |
> |
45 |
> This discussion is very interesting! |
46 |
> If I take this double layer of dependencies, I have to check how this |
47 |
> influences the theory underlying my tool. |
48 |
> |
49 |
> However, I still doubt that only storing the soname dependencies is enough. |
50 |
> Consider package A (that cannot be recompiled) that depends on package B |
51 |
> which provides lib L.so. |
52 |
> B is recompiled with different use flags, which put different |
53 |
> functionalities in L.so. |
54 |
> The dependencies of A are still satisfied (B is installed, L.so is |
55 |
> available), but since the content of L.so changed, A cannot execute anymore. |
56 |
> Hypothetically, can this scenario occur? |
57 |
> Can this scenario occur in practice? |
58 |
> Is there a way in emerge/portage to avoid it? |
59 |
> |
60 |
|
61 |
> |
62 |
> > Well, there are a lot of upgrades that can't be performed without |
63 |
> > temporarily breaking something, so the "forbid broken dependencies" idea |
64 |
> > doesn't sound feasible to me. |
65 |
> |
66 |
> Could you tell me about several instances of such needed dependency |
67 |
> breakage? |
68 |
> You have far more experience than me on this, and it would be nice for me |
69 |
> to know what I'm up against. |
70 |
> |
71 |
|
72 |
A lot of this has to do with the specifics of how package managers manage |
73 |
system state, as well as various quirks of subsets of the tree. For |
74 |
example, a perl upgrade (X->Y) will often break perl modules who expect |
75 |
perl-X, but get perl-Y. So one fix is to try to keep perl-X installed (so |
76 |
we SLOT perl and have N perls installed.) Then you need to decide which |
77 |
version of perl to build things against (X or Y, or both?) We took this |
78 |
tactic in the python ecosystem; but perl is not slotted in Gentoo, and so |
79 |
upgrading perl breaks all perl modules. There is a tool |
80 |
(gentoo-perl-cleaner) that will walk the deptree and fix all of these |
81 |
broken packages that you run after an upgrade. |
82 |
|
83 |
I'm not sure it's strictly avoidable. You could build perl-Y, then rebuild |
84 |
all perl-modules against perl-Y, then merge the entire result to the |
85 |
livefs. This will reduce the breakage time but likely not eliminate it; |
86 |
plus it seems hard to implement in practice without modern filesystem tools |
87 |
(overlayfs, btrfs, zfs or similar tech to make it atomic.) It also doesn't |
88 |
account for executing code. What happens to perl-X code that is executing |
89 |
when you unmerge perl-X? The short answer is that code might break and |
90 |
'proper' management means you should restart services after an upgrade |
91 |
(something Gentoo doesn't typically do; but is common in Debian for |
92 |
example.) |
93 |
|
94 |
-A |
95 |
|
96 |
|
97 |
> Many thanks! |
98 |
> Michael |
99 |
> |
100 |
> |