Re: [gentoo-pms] [PATCH 1/3] dependencies: Permit {,B}DEPEND in source-initiated pkg_setup

[Ulrich Mueller]

>>>>> On Thu, 04 Oct 2018, Michał Górny wrote:

> Account for build dependencies being satisfied in pkg_setup, when
> executed as part of source build, in order to match the realistic
> implementation and widespread use in Gentoo.  This changes pkg_setup
> from the previous state of no dependencies being guaranteed.

> Firstly, this matches the standard package manager implementation
> better.  Since pkg_setup is executed as part of the sequence of
> successive phases comprising a source build, it is natural that build
> dependencies are installed already when it's executed, and not between
> pkg_setup and src_unpack.

> Secondly, it accounts for widespread use of pkg_setup to determine
> installed dependencies in order to set the build environment
> appropriately.  This is a case e.g. with python-any-r1 or llvm eclasses,
> which query installed packages in order to determine the Python or LLVM
> version to use, appropriately.  This behavior can't be changed without
> major changes to a large number of ebuilds, and without making ebuild
> development harder.

> Technically, we could extend the same rule to RDEPEND being satisfied
> when package is going to be installed.  However, this would restrict
> the flexibility of parallel builds.  With regard to the current rules,
> the package manager can start building package from sources before all
> of its runtime dependencies are installed.  The unclear benefit
> of having RDEPEND satisfied in pkg_setup does not seem to justify losing
> this possibility.

> Signed-off-by: Michał Górny <mgorny@g.o>
> ---
>  dependencies.tex | 12 ++++++++----
>  1 file changed, 8 insertions(+), 4 deletions(-)

> diff --git a/dependencies.tex b/dependencies.tex
> index deb5d9c..65ec074 100644
> --- a/dependencies.tex
> +++ b/dependencies.tex
> @@ -11,9 +11,12 @@
>        \multicolumn{1}{c}{\textbf{Phase function}} &
>        \multicolumn{1}{c}{\textbf{Satisfied dependency classes}} \\
>        \midrule
> -      \t{pkg_pretend}, \t{pkg_setup}, \t{pkg_info}, \t{pkg_nofetch} &
> +      \t{pkg_pretend}, \t{pkg_info}, \t{pkg_nofetch} &
>            None (ebuilds can rely only on the packages in the system~set) \\
>        \addlinespace
> +      \t{pkg_setup} & same as \t{src_unpack} if executed as part of source build,

s/same/Same/ for consistency with the previous row (and with other tables).

> +          same as \t{pkg_pretend} otherwise \\
> +      \addlinespace
>        \t{src_unpack}, \t{src_prepare}, \t{src_configure}, \t{src_compile}, \t{src_test},
>            \t{src_install} & \t{DEPEND}, \t{BDEPEND} \\
>        \addlinespace
> @@ -44,9 +47,10 @@
>  There are three classes of dependencies supported by ebuilds:
 
>  \begin{compactitem}
> -\item Build dependencies (\t{DEPEND}). These must be installed and usable before any of
> -    the ebuild \t{src_*} phase functions is executed. These may not be installed at all
> -    if a binary package is being merged.
> +\item Build dependencies (\t{DEPEND}). These must be installed and usable before the \t{pkg_setup}
> +    phase function is executed as a part of source build and throughout all \t{src_*} phase
> +    functions executed as part of that build. These may not be installed at all if a binary package
> +    is being merged.
>  \item Runtime dependencies (\t{RDEPEND}). These must be installed and usable before
>      the results of an ebuild merging are treated as usable.
>  \item Post dependencies (\t{PDEPEND}). These must be installed at some point before
> --
> 2.19.0

Ack.

With respect to RDEPEND in pkg_setup, also note the following discussion
in 2011 (where you came to the same conclusion for another reason):
https://archives.gentoo.org/gentoo-pms/message/ae52de8d7aae179166794a3bac873a68

Ulrich