[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,
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
signature.asc
Description: PGP signature