Gentoo Archives: gentoo-portage-dev

From: michael.lienhardt@×××××××.net
To: gentoo-portage-dev@l.g.o
Cc: Zac Medico <zmedico@g.o>
Subject: Re: [gentoo-portage-dev] precisions on installed packages' dependencies
Date: Fri, 27 Mar 2020 14:00:04
In Reply to: Re: [gentoo-portage-dev] precisions on installed packages' dependencies by Alec Warner
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
6 > > B is recompiled with different use flags, which put different
7 > > functionalities in
8 > > The dependencies of A are still satisfied (B is installed, is
9 > > available), but since the content of 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?
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.)
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.
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.
51 Best,
52 Michael