Simon,

Simon South 写道：
> Am I right in thinking there is no way to specify dependencies 
> among the
> outputs of a single package?

Well, yes, but probably not in the way you mean: they aren't 
specified at all.  Oh dear, nckx's responding to a question about 
‘dependencies’.  Apologies to those who know what's coming.

I avoid the word dependency when discussing Guix and urge you to 
do the same.  It's too ambiguous to be useful.  Some distributions 
use terms like ‘run-time dependency’ or ‘build dependency’ as if 
they're similar, but to me Guix/Nix prove that they're unrelated 
by treating them very differently.  We have inputs, which are 
specified by humans (or implicitly by the build system), and 
references -- which are not[0].

Inputs are built or downloaded when building a package, but only 
references -- the actual occurence of the string 
/gnu/store/<hash>-<package>-<version> in another 
/gnu/store/<subdirectory> -- determine which of those inputs are 
actually relevant after the build has finished.  Only referenced 
store items will be kept around during the next GC or downloaded 
when installing pre-built substitutes.

> To specify that a package's "out" output depends on its "lib" 
> output, for instance.

So it's the build process itself that specifies this: when it's 
complete, /gnu/store/<...>-knot-3.0.1 (:out) may or may not retain 
a reference to /gnu/store/<...>-knot-3.0.1-lib (:lib), and that's 
what determines whether or not :out depends on :lib.

I suspect the majority of packages with a :lib output do so.

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.

> I ask because the Knot package (in gnu/package/dns.scm) builds a 
> number
> of logically distinct targets---daemon, libraries, 
> administrative
> utilities, general-purpose utilities, and documentation---and it 
> would
> be nice to separate at least some of these into individual 
> outputs

Separating tools into administrative vs. general-purpose goes too 
far.

Attached patch:

  $ guix size /gnu/store/...-knot-3.0.1-doc
  total: 0.2 MiB (no references)
  $ guix size /gnu/store/...-knot-3.0.1-lib
  total: 145.0 MiB (self: 2.4 MiB)
  $ guix size /gnu/store/...-knot-3.0.1
  total: 171.1 MiB (self: 5.2 MiB; refers to :lib)
  $ guix size /gnu/store/...-knot-3.0.1-tools
  total: 164.9 MiB (self: 0.4 MiB; refers to :lib)

Old monolithic knot:

  $ guix size /gnu/store/...-knot-3.0.1
  total: 171.5 MiB (self: 8.0 MiB)

> [only the libraries end up a dependency of] Knot Resolver.

Correct.  Building knot-resolver with only ("knot:lib" ,knot 
"lib"):

  $ guix size /gnu/store/...-knot-resolver-5.1.3
  total: 169.1 MiB

Old monolithic knot:

  $ guix size /gnu/store/...-knot-resolver-5.1.3
  total: 183.0 MiB

A saving of 13.9 MiB or <10% is not considered impressive.  Some 
might say it's not worth the complexity although I'm OK with it.

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

> I've searched and can't find an example of this being done, nor 
> can I
> find any mention of it in the documentation. So I assume it's 
> simply not
> possible, and you would need to define an entirely separate 
> package that
> builds from the same source code---right?

Which other examples or documentation have you read?  How would 
you consider Knot more complex or problematic?

Kind regards,

T G-R

[0]: I'm ignoring propagated-inputs, both to simplify things and 
because it makes me happy.