Re: [PATCH] gnu: Add Nmap.

[Taylan Ulrich Bayırlı/Kammer]

address@hidden (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