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:

[...]

>> The whole functional approach things means that bindings are static
>
> That's a neat analogy. :-)

It’s not just an analogy, it’s really what happens.

> However, we needn't recompile C code when there's an update to some
> dynlang library the program uses, do we?

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

Most of the time, packages check at configure-time whether their
perquisites are available.  Then, their test suite use these specific
dependencies.  Finally, in the case of DSOs, the RUNPATH makes sure that
these specific dependencies are used at run time.

Then there’s the case of dynamic languages with no RUNPATH equivalent.
In that case we arrange with ‘propagated-inputs’ or with wrappers to
make sure the “right” dependencies are used at run time.

I’m not sure if that answers your concerns, does it?

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

At the very least, the RUNPATH will be different.

But then, keep in mind we’re aiming for complete reproducibility.  So we
can’t rely on things like “oh, developers say this version is
ABI-compatible with the previous one.”

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

That’s an important effect: it means that the test suite is known to
work this particular input.

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

Yeah, I see where you’re going.  :-)  Eelco Dolstra’s PhD thesis on Nix
had that idea of “equivalence classes”.  It’s not very practical, though.

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

See “Security Updates” in the manual for that.

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

Correct.  That’s why we’d either use ‘propagated-inputs’ or
‘wrap-program’, depending on the situation.

I hope this clarifies things.

So, where were we with this nmap patch?  :-)

Ludo’.