all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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 --]

  reply	other threads:[~2020-10-15 22:26 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-14 22:32 Specifying dependencies among package outputs? Simon South
2020-10-14 22:55 ` Brett Gilio
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

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