From: Tobias Geerinckx-Rice <me@tobias.gr>
To: Simon South <simon@simonsouth.net>
Cc: help-guix@gnu.org
Subject: Re: Specifying dependencies among package outputs?
Date: Fri, 16 Oct 2020 00:26:13 +0200 [thread overview]
Message-ID: <87imbbazy2.fsf@nckx> (raw)
In-Reply-To: <87o8l3h746.fsf@simonsouth.net>
[-- Attachment #1: Type: text/plain, Size: 2868 bytes --]
Simon,
Simon South 写道:
> Thank you Brett, Julien and Tobias for your responses. They've
> been
> super helpful and have cleared things up for me quite a bit.
Very happy to hear that!
> This also clears up for me a bit of remaining confusion around
> the
> distinction between "inputs" and "propagated inputs": I wondered
> why, if
> a package's inputs are its dependencies, the "propagated-inputs"
> field
> is needed at all since surely a package's inputs would always be
> installed alongside it. The explanation is that a package's
> inputs are
> _not_ its dependencies; they are merely inputs to its build
> process, and
> whether one becomes a "dependency" depends entirely on whether a
> reference to it remains in any of the package's outputs. The
> "propagated-input" field is used to ensure this association is
> made,
> even when there is no apparent reference (that Guix can find) in
> the
> outputs.
Yes, P-Is are a bit of a hack outside of the simple functional
model.
Note that they're not equivalent to (say) simply echoing some
store references into a /gnu/store/foo/.propz text file. They
affect the resulting profile as if they had been explicitly
installed into it. Knot keeps a reference to fstrm, but ‘guix
install knot’ will not make ‘fstrm_capture’ appear in your $PATH.
If it were propagated, it would.
Propagation is evil and indispensable.
> Tobias Geerinckx-Rice <me@tobias.gr> writes:
>> If you apply the patch below you'll see (e.g., with ‘guix
>> size’) that
>> installing only knot:tools will pull in knot{:out,:lib} without
>> any
>> human-made hints to that effect.
>
> Thank you for this! This is amazing, and exactly the sort of
> thing I had
> in mind. (Though I wonder if the "tools" output would better be
> called
> "utils", to match the isc-bind package?)
Rather not. I dislike pointless abbreviation. I'm not alone[0].
I don't think matching BIND provides value.
> Are you planning on committing these changes? I think they're
> great.
Sure. I'll move all of /bin to :tools, since I'm defining :tools
as ‘reasons I install knot on my laptop’.
I'll keep /sbin in :out. Some of its commands could be useful
even without a [running] knotd but I don't think it's likely.
Sound good?
>>> However, Knot's daemon and utilities have the same dependency
>>> on its
>>> own libraries, so pulling those into a separate "lib" output
>>> would be
>>> liable to break everything else.
>>
>> Why?
>
> Assuming you didn't mean this rhetorically:
Not at all. I don't consider rhetorical ‘Why?’s useful and am
always interested in the answers. Thanks for taking the time to
respond at length. I'll read it at my leisure.
Kind regards,
T G-R
[0]: http://issues.guix.gnu.org/43881#3
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]
next prev parent reply other threads:[~2020-10-15 22:26 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-14 22:32 Specifying dependencies among package outputs? Simon South
2020-10-15 0:07 ` Julien Lepiller
2020-10-15 0:37 ` Tobias Geerinckx-Rice
2020-10-15 0:43 ` Tobias Geerinckx-Rice
2020-10-15 11:44 ` zimoun
2020-10-15 14:54 ` Simon South
2020-10-15 22:26 ` Tobias Geerinckx-Rice [this message]
2020-10-15 23:45 ` Simon South
2020-10-16 17:32 ` Tobias Geerinckx-Rice
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
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87imbbazy2.fsf@nckx \
--to=me@tobias.gr \
--cc=help-guix@gnu.org \
--cc=simon@simonsouth.net \
/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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).