[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-portage-dev
Subject:    Re: [gentoo-portage-dev] precisions on installed packages' dependencies
From:       michael.lienhardt () laposte ! net
Date:       2020-03-30 21:55:31
Message-ID: 110711371.15092330.1585605331527.JavaMail.zimbra () laposte ! net
[Download RAW message or body]


----- 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


[prev in list] [next in list] [prev in thread] [next in thread]