l...@gnu.org (Ludovic Courtès) writes: > This is normally dealt with by using multiple outputs (info "(guix) > Packages with Multiple Outputs"). An example of that is Git: the Tcl > GUIs are moved to a separate output, and so is git-svn support, such > that the main output does not depend on Tcl, libx11, Subversion, etc.
OK, will have a go at this. It seems Zenmap doesn't need X11/GTK libraries (rather headers) at build time because it only uses a Python GTK module. This raises two general questions for me: 1) Is it OK if users have to install additional packages for a given component of a package to work, or should all dependencies, even if purely run-time, be inputs? 2) If purely-run-time dependencies are inputs, won't that trigger unnecessary rebuilds of the package when a run-time dependency is updated? (In this special case only question 2 applies, because the whole of Zenmap is useless without GTK, not just a component of it.) After some pondering, I would say: 1) There should be a way to run-time-depend on another package without it being a build input at all. (The installation of these needn't be forced on the user, though in some cases like Zenmap it's senseless not to do so; we could have "dependencies" and "recommendations" and possibly more, like in Debian.) 2) When interface files of a dylib are needed during compilation of a static lang (e.g. C headers), a special for-building package should be used as input, thus the actual dylib can be updated without causing rebuilds. (Until ABI compatibility breaks I guess.) 3) Similarly, when a program is needed purely at build-time, like Bash or SCons, a special for-building package should be used as input, thus the actual program can be updated without causing rebuilds. (The for-building package would be updated only when doing so will improve the builds, like when a newer GCC version optimizes better.) 4) The for-building packages in #3 should obviously not be installed on the user's machine (unless they build locally instead of using binary substitutes), meaning "build inputs" and "run-time dependencies" are fully orthogonal. In the Nix manual I see the following, which possibly fixes #4 without needing to separate build inputs from run-time dependencies in recipes: "Runtime dependencies are found by scanning binaries for the hash parts of Nix store paths (such as r8vvq9kq…). This sounds risky, but it works extremely well." Perhaps we already do that? But otherwise, it seems like we could save gigawatts of electricity over time with #1-3. Please tell me if I'm missing something obvious. :-) Taylan
