bug#26170: Bug #26170 Hunting: doc: Explanation of propagated-inputs unclear

["pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de>]

[-- Attachment #1: Type: text/plain, Size: 2283 bytes --]

Thank you for bringing up this bug again with detailed
cross-referencing.  Sorry for not sending a patch earlier.

I do not think it makes sense to close yet.  I attach a proposed patch
now (its text is not properly wrapped yet).  It may contain
misunderstandings about propagated inputs as I have not packaged much.

On Wed, Sep 09, 2020 at 03:25:31PM +0200, zimoun wrote:
> Currently, the term “propagated inputs” in the index [2] goes to the
> section “Invoking guix package” [3] and explaining:
> 
>         Sometimes packages have propagated inputs: these are
>         dependencies that automatically get installed along with the
>         required package (see propagated-inputs in package objects, for
>         information about propagated inputs in package definitions).
> 
>         An example is the GNU MPC library: its C header files refer to
>         those of the GNU MPFR library, which in turn refer to those of
>         the GMP library. Thus, when installing MPC, the MPFR and GMP
>         libraries also get installed in the profile; removing MPC also
>         removes MPFR and GMP—unless they had also been explicitly
>         installed by the user.
> 
> with the hyperlink [4] mentioning:

Note the text currently in the manual is the same as back then when I
filed the bug.

When starting to read about propagated inputs in the documentation of
`guix package --install`, I agree, it is clear enough, the reader will
understand that propagated inputs get treated like with `guix package
--install` and the reader need not think about profiles and the store.

However, back then I may have gotten confused because I started off
reading the Defining Packages section without the context of `guix
package --install`.  In this context, I may have been thinking of
installation to a directory rather than a user running `guix install`.


> 3) more examples like the above example for GNOME Evolution (which
> however I have yet to finish packaging and submit as a patch; maybe
> dconf is a better example – I presume it is also needed at run time and
> not just).

I was mistaken about 3).  I am glad Ricardo Wurmus packaged Evolution.
Apparently I was wrong and evolution does not need
evolution-data-server as a propagated-input.

Regards,
Florian

[-- Attachment #2: 0001-doc-Clarify-what-propagated-inputs-are.patch --]
[-- Type: text/plain, Size: 2186 bytes --]

From fd4955cd0a61e92c37a371e4c5411a505ad5ac76 Mon Sep 17 00:00:00 2001
From: Florian Pelz <pelzflorian@pelzflorian.de>
Date: Wed, 9 Sep 2020 16:54:04 +0200
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: [PATCH] doc: Clarify what propagated inputs are.

Fixes <https://issues.guix.info/issue/26170>.

* doc/guix.texi (package Reference)[package-propagated-inputs]: Clarify.
---
 doc/guix.texi | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 1d6782e6fa..0a5640b174 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -6360,21 +6360,21 @@ this area (@pxref{Invoking guix lint}).
 
 @anchor{package-propagated-inputs}
 Lastly, @code{propagated-inputs} is similar to @code{inputs}, but the
-specified packages will be automatically installed alongside the package
+specified packages will be automatically installed to profiles (@pxref{Features, the role of profiles in Guix}) alongside the package
 they belong to (@pxref{package-cmd-propagated-inputs, @command{guix
 package}}, for information on how @command{guix package} deals with
 propagated inputs).
 
-For example this is necessary when a C/C++ library needs headers of
+For example this is necessary when packaging a C/C++ library that needs headers of
 another library to compile, or when a pkg-config file refers to another
 one @i{via} its @code{Requires} field.
 
 Another example where @code{propagated-inputs} is useful is for languages
 that lack a facility to record the run-time search path akin to the
 @code{RUNPATH} of ELF files; this includes Guile, Python, Perl, and
-more.  To ensure that libraries written in those languages can find
-library code they depend on at run time, run-time dependencies must be
-listed in @code{propagated-inputs} rather than @code{inputs}.
+more.  When packaging libraries written in those languages, ensure they can find
+library code they depend on at run time by listing run-time dependencies
+in @code{propagated-inputs} rather than @code{inputs}.
 
 @item @code{outputs} (default: @code{'("out")})
 The list of output names of the package.  @xref{Packages with Multiple
-- 
2.28.0