Re: [PATCH] gnu: Add Nmap.

[ludo@gnu.org (Ludovic Courtès)]

taylanbayirli@gmail.com (Taylan Ulrich "Bayırlı/Kammer") skribis:

> ludo@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.

Thanks, that seems like the best option.

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

Yes.  (There may be rare exceptions, but this is not one of them.)

Here you want users to be able to run ‘zenmap’ (or whatever the command
is called) and have it Just Work, regardless of whether they happen to
have installed Python and Python-GTK as well.

So that means that the zenmap (or nmap) package basically needs to
“close over” these inputs, probably using ‘wrap-program’.

> 2) If purely-run-time dependencies are inputs, won't that trigger
>    unnecessary rebuilds of the package when a run-time dependency is
>    updated?

It’s rarely be “purely run-time”.  Normally, at the very least there’s a
configure script that makes sure at build-time that the dependencies are
satisfied, and a test suite that makes sure things work.

> 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 whole functional approach things means that bindings are static
(again, there may be exceptions, but zenmap has nothing exceptional
here.)

> 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.)

You’re describing an imperative packaging system.  This is fine, but it
defeats the whole idea of functional packaging.  :-)

See <http://nixos.org/docs/papers.html> and
<http://gnu.org/s/guix/#documentation> for the rationale.

> 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.)

Build tools are listed in ‘native-inputs’.

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

Yes.  That means that run-time dependencies are a strict subset of
build-time dependencies.

I hope this clarifies things.  Otherwise let me know!

Thanks,
Ludo’.