Re: Specifying dependencies among package outputs?

[Tobias Geerinckx-Rice]

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

whether one becomes a "dependency" depends entirely on whether a
reference to it remains in any of the package's outputs. The

outputs.

installed alongside it. The explanation is that a package's inputs are _not_ its dependencies; they are merely inputs to its build process, and "propagated-input" field is used to ensure this association is made, even when there is no apparent reference (that Guix can find) in the

Propagation is evil and indispensable.

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.

Tobias Geerinckx-Rice <m...@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.

"utils", to match the isc-bind package?)

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

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.

Sound good?

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.

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:

Kind regards,

T G-R

[0]: http://issues.guix.gnu.org/43881#3

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.

signature.asc
Description: PGP signature