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: Mon, 30 Mar 2020 21:55:46
In Reply to: Re: [gentoo-portage-dev] precisions on installed packages' dependencies by Alec Warner
1 ----- Alec Warner <antarus@g.o> a écrit :
3 > Sorry I'm being overly academic. My concern earlier is that you mentioned a
4 > goal of "never breaking installed packages' which I found to be a fairly
5 > audacious goal. The idea is that we should build tools that achieve this
6 > practically (e.g. via heuristics such as := slot operators) while
7 > understanding that the complexities of application deploys are legion and
8 > the tool will never handle them all. So the goal of never breaking them is
9 > more an idealistic goal rather than a practical reality.
11 I agree.
12 I started this discussion because I thought that the content of the /var/db/pkg/* folder was not enough to keep the dependencies.
13 Then Zack and you showed me that I only saw the tip of the iceberg (in my defense, I first wanted to only keep the package's abstract dependencies, not the ones of the actual code. And then the discussion was really interesting).
14 My experience in dependency management is limited to an extended model of debian packages, so my question were (and will be) naive.
16 I understand that with the current status of Portage:
17 - we can consider that the dependencies specified in a package ensure that it can be installed and run
18 - however, package update and package removal is not guaranteed to work. Slot operators is an integrated way to capture some update behaviors, but not all. In general, a dedicated method (like for perl) can be needed.
20 I do believe that never breaking dependencies (at the code level) is a nice idealistic goal.
21 It might not always be possible to achieve it, but you did talk of much work done to do it where it is possible.
22 And, to come back to my previous question, I imagine that the slot operator is an ad-hoc but very useful to avoid dependency breakage when possible.
23 However, this operator looks strange to me: my (naive) intuition to express a trigger for package recompilation would be the other way around (i.e., it is the package that is updated that says what changes, and so, which other packages must be recompiled); like you illustrated with perl, an external tool (possibly different for each package) that gives which packages must be recompiled due to a specific package update.
24 This is why I asked why is the slot operator better as a recompilation trigger compared to other approaches? Is it because it only requires for the developer to add a "=" sign (simplicity is very important)? Or for another reason?
26 Many thanks!
27 Michael