[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Specifying dependencies among package outputs?

From: Tobias Geerinckx-Rice
Subject: Re: Specifying dependencies among package outputs?
Date: Fri, 16 Oct 2020 00:26:13 +0200


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

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


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,



Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]