practicality of custom config

practicality of custom config

[Michael Zucchi]

Morning,

 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.

Looking through the package definitions it looks like considerable 
effort: either editing or using code to edit (aka deriving) every 
package that uses it.  For deriving changes it would require internal 
knowledge of the source package definition and would thus be rather 
fragile and difficult to maintain.

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?

  Z

Re: practicality of custom config

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 444 bytes --]

Hi Michael,

Indeed, in practice it's not easy to tell Guix "build a system without
sound" or things like that.

An option would be to implement a feature à-la USE flags (as in Portage
on Gentoo).
This was discussed previously here:

https://lists.gnu.org/archive/html/guix-devel/2019-05/msg00285.html

I'm planning to work on it in the coming weeks.  Feedback welcome!
Stay tuned!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: practicality of custom config

[Michael Zucchi]

On 31/12/19 8:20 pm, Pierre Neidhardt wrote:
> Hi Michael,
>
> Indeed, in practice it's not easy to tell Guix "build a system without
> sound" or things like that.

But I'm just using guix atop slackware64, and sound already works fine.  
There was no need to derisively misquote part of my query.

> An option would be to implement a feature à-la USE flags (as in Portage
> on Gentoo).
> This was discussed previously here:
>
> https://lists.gnu.org/archive/html/guix-devel/2019-05/msg00285.html
>
> I'm planning to work on it in the coming weeks.  Feedback welcome!
> Stay tuned!
>

Ok cheers, that's the sort of thing I was curious about.  It seems involved.

  Z

Re: practicality of custom config

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 540 bytes --]

Michael Zucchi <notzed@gmail.com> writes:

>> Indeed, in practice it's not easy to tell Guix "build a system without
>> sound" or things like that.
>
> But I'm just using guix atop slackware64, and sound already works fine.  
> There was no need to derisively misquote part of my query.

Oh, sorry for the misunderstanding, I didn't mean to misquote you, I was
just giving an example in the style of Gentoo USE flags.  The same holds
for "build without GUI support" for instance.

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

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