[Nix-dev] gnutls broken

[Yury G. Kudryashov]

Ludovic Courtès wrote:

First of all, you're the maintainer of gnutls, so do what you want. It would 
be nice if default gnutls (i.e., the gnutls used to build all other 
packages) will not depend on guile.
You can add
  gnutls_guile = gnutls.override { enableGuile = true; };
to let hydra build both.

> Hi Yury,
> 
>> We can have gnutls and gnutls_guile. But this means that every user who
>> installs gnutls_guile will have two libgnutls.so.
> 
> Again, the way this is usually done is as written above: with parameters
> saying which optional features of the package should be enabled.
Actually, I see three ways:
1. Add a flag that user can override.
2. Make a multi-output derivation.
3. Create several derivations.

Also I see a few very different use cases:
A. X installs an executable/library that can be optionally linked to a 
library from package Y.
    Example: vim.
B. X installs a few executables/libraries some of them can be optionally 
linked to a library from package Y.
    Example: d-bus.
C. X installs some executables/libraries and installs more libraries (e.g., 
bindings or plugins) if optional dependencies were found.

In case A the only possible way is 1.

What to do in case B highly depends on the details.

In case C all three ways are possible. Some pros and cons of each way in 
this use case.
1. An overridable option
------------------------
Pros:
* Easy to implement and maintain.
Cons:
* If user needs two different configurations, his /nix/store will contain 
two copies of common libraries.
* If user needs two different configurations, he'll have to compile common 
part twice.

2. Multiple-output derivation
-----------------------------
Haven't tried to implement, so don't know whether it is difficult.
Pros:
* User can garbage-collect unused outputs.
Cons:
* Those who build from sources have to build all the optional dependencies 
to compile the 'base' package.
* The above item may lead to false build dependency cycles.

3. Splitting into two derivations
---------------------------------
Pros:
* No false build dependencies.
* No unneeded rebuilds.
* Do not waste space in the store and build cycles.
Cons:
* Needs (ugly) patches to the build system.
* Because of the item above, needs review on each upgrade.
-- 
Yury G. Kudryashov,
mailto: urkud at mccme.ru