Hmm… My initial idea was to tag how packages are used, rather than how packages are made. The aim being to support things like using
glib as a dependency, while only relying on the headers part of it.
glib could be a binary-only dependency, it wouldn’t matter much, as only source code is used from it. This also answers why
coreutils would be binary dependencies: they are used as binaries.
Now, upon giving it a bit more thought, I’m no longer sure this is really useful. I guess I missed the “infection” part of your proposal, when writing this message!
Indeed, so with the infecting
meta.binary attribute, I guess one option would be to have a nixpkgs configuration option
allowBinary: derivation -> bool, that would allow (or not) installing a binary by doing something like
all $ map (d: isBinary d || allowBinary d) transitiveDeps on the transitive dependencies of each to-be-installed package?
Indeed, I’m not really suggesting we turn this on by default on
hydra (although this may be something that works, so long as the root of the tree is “carved in stone” – it shouldn’t require many changes anyway, so maybe the cost would be palatable?). However, it would may make sense for paranoid-enough individuals
Now comes the question of how to migrate from the current “don’t tag anything” to tagging all derivations as either binary or built-from-source. I think that, for safety,
meta.binary should default to
true. But requiring a change to all derivations in nixpkgs sounds impossible.
So maybe just set
meta.binary that defaults to
true for the fetching builtins? With this, all packages that come from outside would be considered as binary by default, and derivations built from other derivations would default to non-binary, which seems to make sense. It would still require quite a bit of work, though.