[Nix-dev] (Optionally) Build same package multiple ways on Hydra
Vladimír Čunát
vcunat at gmail.com
Wed Jun 11 08:03:59 CEST 2014
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 have
>
> Foo.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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3251 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20140611/7c408154/attachment.bin
More information about the nix-dev
mailing list