all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de>
To: zimoun <zimon.toutoune@gmail.com>
Cc: 26170@debbugs.gnu.org
Subject: bug#26170: Bug #26170 Hunting: doc: Explanation of propagated-inputs unclear
Date: Wed, 9 Sep 2020 17:10:21 +0200	[thread overview]
Message-ID: <20200909151021.dnte7uodi3gj5t6r@pelzflorian.localdomain> (raw)
In-Reply-To: <87h7s7ulo4.fsf@gmail.com>

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


  reply	other threads:[~2020-09-09 15:11 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-19  7:03 bug#26170: documentation: Explanation of propagated-inputs unclear pelzflorian (Florian Pelz)
2019-12-03 12:14 ` bug#26170: Bug #26170 Hunting: doc: " zimoun
2019-12-03 12:49   ` pelzflorian (Florian Pelz)
2020-09-09 13:25     ` zimoun
2020-09-09 15:10       ` pelzflorian (Florian Pelz) [this message]
2020-09-09 15:45         ` zimoun
2020-09-16 10:37         ` Ludovic Courtès
2020-09-16 13:27           ` pelzflorian (Florian Pelz)
2020-09-17 19:45             ` Ludovic Courtès
2020-09-18  9:08               ` pelzflorian (Florian Pelz)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200909151021.dnte7uodi3gj5t6r@pelzflorian.localdomain \
    --to=pelzflorian@pelzflorian.de \
    --cc=26170@debbugs.gnu.org \
    --cc=zimon.toutoune@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.