[bug#68010] [PATCH] home: services: Add home-zathura-service-type.

[Ludovic Courtès]

Hello,

Sergey Trofimov <sarg@sarg.org.ru> skribis:

> lgcoelho@disroot.org writes:
>
>> This service enables a declarative configuration of zathura, the
>> customizable document viewer.
>
> I have mixed feelings about pulling 3rd-party software configurations
> in guix:
> - adding it to guix increases maintenance burden: new versions   could
>  add or remove config options
> - it bloats guix: imagine if we add configs for every
>   user-configurable app
> - such configs are not easily transferrable: if I were to use the
>   same app in non-guix env, I'd have to maintain 2 configs
>
> Another recent example is `oci-container-configuration` which defines
> a subset of docker-cli startup arguments. The problem is that `docker
> run` command has 96 options and the configuration only uses a handful,
> lacking a way to provide the remaining ones.
>
> I think guix should not embed config generators for user software. The
> only need I see for such generators is when there are options which
> should be the same among multiple applications (e.g. color schemes or
> shared directories). For such usecase guix should provide better text
> manipulation tools which home owners could use to parameterise
> configs.

I guess it’s a tradeoff.  The usual approach for System/Home services
has been to provide “bindings” (a record type) for the config, *plus* an
“escape hatch” (letting users pass raw config as a string).

But you’re right, the expected maintenance burden should be taken into
account.  For well-established software and config formats such as Git,
it’s probably okay to have bindings; for things that are more
recent/changing, it’s less obvious.  Also, we currently don’t have tests
for Home services, except for those mapped from System services, which
means breakage isn’t automatically detected.

I don’t know whether Zathura falls in the “okay” category or rather in
the “let’s do write bindings” one.

Ludo’.