Re: [PATCH] gnu: Add Nmap.

[Taylan Ulrich Bayırlı/Kammer]

address@hidden (Ludovic Courtès) writes:

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

Thanks for the pointer; I'll look into '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.

You're right; now that I think of it, it's probably a bug that Nmap's
build process doesn't check for the presence of a GTK module.  I'll talk
to their developers to clarify.  (ML thread should pop up at the bottom
of http://seclists.org/nmap-dev/2014/q4/index.html soon.)

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

That's a neat analogy. :-) However, we needn't recompile C code when
there's an update to some dynlang library the program uses, do we?

Then again, we want to re-run a potential test suite that might be using
that library.  I guess it's OK to be "conservative" for now, until One
Day™ we can be more precise and separate testing from building...

(If that day comes though, we better find a way to automatically discern
run-time-only inputs.  (Regarding test suites to be "run-time" too.)
Otherwise we'll have a lot to do.)

Also, configure scripts that check for such dynlang libraries' presence
might become a problem.  I imagine one could provide some for-building
version of said library that's merely of the same major version, to
"shut up" the configure script, since it only gets in the way in this
case.  (Complaining about the lack of a run-time dependency, at
build-time...  Yes, above I said *not* doing this is probably a bug in
Nmap's build process, but for us it would become an annoyance.)
Alternatively, the script might simply take a flag telling it to enable
a feature even if it can't find a run-time dependency; I don't how many
configure scripts have this.

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

Same thing as above really.  Until the ABI of a dylib changes, updates
to it needn't ignite recompilation of C code which uses that lib; it
won't affect the compiler output anyway.  (Tell me if I'm technically
wrong; not an expert on C compilation etc.)  But again, test suites...

It does sound like breaking functional purity, but is it really so when
an input has *no* effect on a build process other than the test suite?
Once the test suite is separated, the real package and for-building
package become operationally equivalent under the given build process,
so providing one in place of the other would be a correctness preserving
optimization. :-)

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

Ah, thanks for clarifying.  (BTW 'native-inputs' seems undocumented.)

In that case, we should already be able to do at least this, no?  (The
other ideas are sadly high up in the air.)  It could have prevented
world-rebuilds upon the bash security patches, for example.  (Given it's
acceptable to use a buggy (even security-holy) Bash for some ./configure
scripts and the like, so long as it doesn't break specifically them.)

>> "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 see.  One confusion remains: wouldn't that mean it would drop a
dependency such as the Python GTK module in our case, because its hash
doesn't appear anywhere, and instead it's only referenced by module name
which is expected to be in some Python load path at run-time?


Thanks a lot and sorry for taking your time!  I might be dumping out
many dubious ideas.

Taylan