<gchristensen>
copumpkin: mark BAP and , llvm37, and llvm38 as broken and see what happens?
<copumpkin>
maurer in the other channel had some advice on BAP and 3.8
<copumpkin>
3.7 definitely appears to be unused
<gchristensen>
cool
<copumpkin>
:D
zarel has quit [(Quit: Leaving)]
<ekleog>
idea : what about a shortcutBuildSteps in derivations, that would list alternative build steps in case all the dependencies are already present in the system (and maybe that wouldn't count towards the derivation's hash, so that it could be stacked without cluttering the files)? It's most likely an horrible idea 'cause I've thought about it only for a few seconds, but could make it easy to insert security
<ekleog>
patches etc. by just listing an alternate way to build the application from the old version
<ekleog>
the “sed all dependencies in place”, which iirc pierron's solution for this issue is about, could then be implemented on top of this “alternate build mechanism” system
<ekleog>
then the major issue would be that a derivation hash no longer uniquely identifies a way of building a package, as depending on which dependency is present at build time the build script is changed, so that'd be one step backwards for reproducible builds I guess
<ekleog>
anyway, just raising the idea :)
<MichaelRaskin>
I think this is called substituters
<MichaelRaskin>
Currently they are all «instead of building, you can just download from binary cache»
<MichaelRaskin>
But they could be more interesting.
<ekleog>
oh that'd be even more general, indeed :) so maybe allowing to configure substituters from the nix-expression instead of just hardcoding the binary caches in nix would be a way to go? then have nixpkgs configure the binary cache for every package
<ekleog>
that'd be a breaking change, though, I guess, so... for nix 1.13 at best?
<MichaelRaskin>
I think you can configure substituters separately via environment variables.
<MichaelRaskin>
Nix expressions are about The True Way To Build.
<MichaelRaskin>
Substituter choice is Local Admin Decision.
<MichaelRaskin>
(even if there are defaults and recommendations)
<ekleog>
hmm, true. but then, the information of “this package can be built by just sed'ing this dependency into this other one” must be encoded along with the package, as it's most likely non-obvious non-automatic property
<MichaelRaskin>
Actually, it is automatically extractable.
<MichaelRaskin>
First, deduplicate files.
<MichaelRaskin>
When two expressions share a large part of space, run bzdiff.
<MichaelRaskin>
If the result is promising, advertise binary diff availability.
<ekleog>
oh, so what you're saying is to build the two derivations in the binary cache, and then to send a diff. what I was thinking about was having a way for the cache to build only one package, and then to sed the updated dependency as a way to build the package built upon library v(n+1) (much like other distro's do when upgrading a .so in-place without upgrading all its reverse dependencies)
<ekleog>
(that said your idea would already be great for the “I always have to re-download the world” issue, indeed :D)
<MichaelRaskin>
It is a tough sell in Nix world to _never ever_ do a proper build of some expression…
<ekleog>
indeed, then this would likely free quite a lot of capacity from hydra, which could then be used to run more automated tests (and also to be able to fully test all PRs before they get merged) -- though I haven't made any detailed analysis of the computation consumption of hydra
<ekleog>
that'd obviously require explicit opt-in of packages, also
<ekleog>
that said with the amount of packages to explicitly opt-in and the difficult choice of whether to opt it in or not, as well as the syntax for describing what kind of upgrades can be handled without a full rebuild... maybe it'd cause more troubles than benefits
<MichaelRaskin>
Look, Hydra doesn't do parallel building (inside a single package), and opt-in for parallel building is more paranoid than it should be
<MichaelRaskin>
I wouldn't overestimate the chances of doing what you want without doing proper builds ever.
<gchristensen>
binary diffing would be cool
<MichaelRaskin>
I think with manifest-based channels we had it.
<MichaelRaskin>
Then binary caches happenned, and they have a lot of cool stuff, but binary diffs stopped being a thing.