* Re: [gentoo-portage-dev] precisions on installed packages' dependencies
@ 2020-03-30 21:55 99% ` michael.lienhardt
0 siblings, 0 replies; 1+ results
From: michael.lienhardt @ 2020-03-30 21:55 UTC (permalink / raw
To: gentoo-portage-dev; +Cc: Zac Medico
----- Alec Warner <antarus@gentoo.org> a écrit :
> Sorry I'm being overly academic. My concern earlier is that you mentioned a
> goal of "never breaking installed packages' which I found to be a fairly
> audacious goal. The idea is that we should build tools that achieve this
> practically (e.g. via heuristics such as := slot operators) while
> understanding that the complexities of application deploys are legion and
> the tool will never handle them all. So the goal of never breaking them is
> more an idealistic goal rather than a practical reality.
I agree.
I started this discussion because I thought that the content of the /var/db/pkg/* folder was not enough to keep the dependencies.
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).
My experience in dependency management is limited to an extended model of debian packages, so my question were (and will be) naive.
I understand that with the current status of Portage:
- we can consider that the dependencies specified in a package ensure that it can be installed and run
- 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.
I do believe that never breaking dependencies (at the code level) is a nice idealistic goal.
It might not always be possible to achieve it, but you did talk of much work done to do it where it is possible.
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.
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.
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?
Many thanks!
Michael
^ permalink raw reply [relevance 99%]
Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
[not found] <1928379103.2245185.1585313194988.JavaMail.zimbra@laposte.net>
2020-03-26 8:06 ` [gentoo-portage-dev] precisions on installed packages' dependencies Alec Warner
2020-03-27 13:59 ` michael.lienhardt
2020-03-28 6:48 ` Alec Warner
2020-03-30 21:55 99% ` michael.lienhardt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox