Le 14 octobre 2020 18:32:27 GMT-04:00, Simon South <si...@simonsouth.net> a écrit : >Am I right in thinking there is no way to specify dependencies among >the >outputs of a single package? To specify that a package's "out" output >depends on its "lib" output, for instance.
The notion of dependencies do not make a lot of sense in guix. We talk about inputs: things that are accessible during the build, but don't really declare which are needed at runtime and which are needed at build-time (granted usually the distinction between native and non native does that job). For tracking runtime dependencies, guix uses another mechanism: when a package holds a reference to another package (by embedding the store path of that other package), it depends on it, anl guix will pull them both. > >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, in >part because we could then specify only the libraries as a dependency >of >Knot Resolver. > >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. > >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? We actually do that for a few programs. Look at mariadb for an example of splitting lependencies to different outputs. Mariadb has binaries that require the libraries. During the build, the library path is recorded in the binaries (using the rpath mechanism). Since the path to the lib output is present in the binary, it dependg on it and that output is pulled by guix. Knot could work the same. Specify the libdir and make sure the libdir path is embedded in the binaries. Then, guix will know that a lependency exists and will pull the libraries. Any package that depends on the library rather than the binary will need to be adjusted to use knot:lib as an input. Other than that, no breakage.
