[Nix-dev] (Optionally) Build same package multiple ways on Hydra

[Mateusz Kowalczyk]

On 06/10/2014 11:18 AM, Vladimír Čunát wrote:
> On 06/10/2014 06:59 AM, Michael Raskin wrote:
>> If the option combination deserves its own Hydra job, it deserves
>> a top-level attribute in all-packages.nix (which is a one-line addition)
>> for ease of use with «nix-env -i».
> 
> Yes, exactly what I think.
> 
> This is important when things are depended on, so it's clear which 
> version is used. I don't think it's sensible to have a library like 
> webkit with everything that depends on it, built in multiple ways.
> 
> 
> Vlada
> 
> 
> 

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 { … }

rather than having to grep through the package list, hoping
Foo-pulseaudio-qt-httpd-noicons package exists. An override is much
easier to the user and if such a configuration was built on Hydra before
then great, fetch the binary but if it wasn't then just build it. It
also makes it unclear what the defaults actually are. Should the vanilla
package be called Foo-nopulse-noqt-nohttpd-icons or just Foo? The user
will certainly type ‘nix-env -i Foo’ first and expect *something* to
install.

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.

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.

-- 
Mateusz K.