Re: practicality of custom config

[Ricardo Wurmus]

Hi,

> From the manual:
>
>    "It is also /customizable/: users can /derive/ specialized package
>    definitions from existing ones, including from the command line (see
>    Package Transformation Options
>    
> <https://guix.gnu.org/manual/en/html_node/Package-Transformation-Options.html#Package-Transformation-Options>).
>    "
>
>
> But in reality how practical would it be to create a system which for
> example doesn't include pulseaudio?  I'm using slackware 64and it
> provides this option so ideally I don't want guix dragging it back in.

“pulseaudio” is a good example because many packages build with its
headers without linking to it.  What’s the right thing to do here when
you want it removed?  In those cases you cannot just remove “pulseaudio”
from the inputs, which is something that the package transformations
mentioned in the manual can easily do.

> Looking through the package definitions it looks like considerable
> effort: either editing or using code to edit (aka deriving) every
> package that uses it.

The package transformations act on the whole package graph recursively,
so it would be enough to write a simple transformer once and apply it to
all leaf nodes that you reference in the list of system packages.

Of course this would mean compiling packages anew, because we don’t
offer binary substitutes for arbitrary package variants.

> This is one example but there may be other system-wide options that
> one might want to customise in a similar way to services, is there a
> mechanism for this?

Package transformers are the generic mechanism to use here, but it is
true that a feature is missing to apply a package transformer on the
*whole* system (and not just the “packages” field of a system
configuration).

Doing something smarter or context aware however cannot easily be done
automatically (as in the case where pulseaudio is needed at build time
merely for its headers but doesn’t result in linking).

--
Ricardo