1 |
----- Alec Warner <antarus@g.o> a écrit : |
2 |
> On Tue, Mar 24, 2020 at 11:31 AM <michael.lienhardt@×××××××.net> wrote: |
3 |
> > However, I still doubt that only storing the soname dependencies is enough. |
4 |
> > Consider package A (that cannot be recompiled) that depends on package B |
5 |
> > which provides lib L.so. |
6 |
> > B is recompiled with different use flags, which put different |
7 |
> > functionalities in L.so. |
8 |
> > The dependencies of A are still satisfied (B is installed, L.so is |
9 |
> > available), but since the content of L.so changed, A cannot execute anymore. |
10 |
> > Hypothetically, can this scenario occur? |
11 |
> > Can this scenario occur in practice? |
12 |
> > Is there a way in emerge/portage to avoid it? |
13 |
|
14 |
|
15 |
> > You have far more experience than me on this, and it would be nice for me |
16 |
> > to know what I'm up against. |
17 |
> |
18 |
> A lot of this has to do with the specifics of how package managers manage |
19 |
> system state, as well as various quirks of subsets of the tree. For |
20 |
> example, a perl upgrade (X->Y) will often break perl modules who expect |
21 |
> perl-X, but get perl-Y. So one fix is to try to keep perl-X installed (so |
22 |
> we SLOT perl and have N perls installed.) Then you need to decide which |
23 |
> version of perl to build things against (X or Y, or both?) We took this |
24 |
> tactic in the python ecosystem; but perl is not slotted in Gentoo, and so |
25 |
> upgrading perl breaks all perl modules. There is a tool |
26 |
> (gentoo-perl-cleaner) that will walk the deptree and fix all of these |
27 |
> broken packages that you run after an upgrade. |
28 |
> |
29 |
> I'm not sure it's strictly avoidable. You could build perl-Y, then rebuild |
30 |
> all perl-modules against perl-Y, then merge the entire result to the |
31 |
> livefs. This will reduce the breakage time but likely not eliminate it; |
32 |
> plus it seems hard to implement in practice without modern filesystem tools |
33 |
> (overlayfs, btrfs, zfs or similar tech to make it atomic.) It also doesn't |
34 |
> account for executing code. What happens to perl-X code that is executing |
35 |
> when you unmerge perl-X? The short answer is that code might break and |
36 |
> 'proper' management means you should restart services after an upgrade |
37 |
> (something Gentoo doesn't typically do; but is common in Debian for |
38 |
> example.) |
39 |
|
40 |
Many thanks for this answer. |
41 |
To sum up what I understood, the problem is not really the dependencies, but which recompilation (and service restart) are triggered with an update. |
42 |
In gentoo, there is the ":=" slot operator (and others similar) in dependencies that trigger the recompilation when the dependency's slot change, but this is the only existing mechanism. |
43 |
And this is why every time perl changes, the compilation of its modules is not triggered and they are most probably broken. |
44 |
Correct? |
45 |
And then, in this context, keeping the installed packages' dependencies consistent is up to debate: packages will get broken in any case... |
46 |
It is clearly impossible to have a tool that automatically detect all implementation dependency breakage. |
47 |
|
48 |
Again, there's something I probably don't see: why was slot operators chosen (among other possibilities) as a mechanism to trigger recompilation? |
49 |
I'm very grateful to you all for the time you take to read and answer my questions. |
50 |
|
51 |
Best, |
52 |
Michael |