On 06/10/2014 08:27 PM, Mateusz Kowalczyk wrote:
That's certainly one way to do it but it poses an issue of having multiple variants of packages at top level which reduces usability: when we want package Foo with pulseaudio, qt, httpd and no icons support then it's much easier to haveFoo.override { … }
You *can* use that even if the variant was defined as an attribute in all-packages.nix. You will get the same derivation (if the setting is the same), so binaries from Hydra. BTW, these top-level attributes are best defined via .override ;-)
Webkit was only used as an example of a large package one might not want/be able to build themselves and I'm not saying that it specifically suffers from this problem.
Yes, I got that. I only used it as an example, too.
Another example is going the other way: say by default something comes with KDE support (and therefore depends on KDE) but we don't want KDE on our system so we set the withKDE flag and suddenly we have to compile it ourselves. I think this raises a separate question of what should the sensible defaults be but if multiple build ways are implemented then this problem is largely mitigated. If we want the packages to be customisable then we need to provide a way to make it easier to do so for common scenarios rather than a single default.
I believe that in most cases the dependencies useful to most people are either small (so mostly OK to have them) or splittable in plugin style. IMO particular cases should be discussed. In general it shouldn't be problem to have Hydra build some things multiple times, but it's better to avoid it where not "necessary".
Vlada
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
