Re: Specify runtime dependencies with propagated-inputs or wrapper scripts

[Leo Prikler]

Hello,

Am Freitag, den 26.03.2021, 20:36 +0100 schrieb Léo Le Bouter:
> Hello!
> 
> I often meet problems where some packages don't work out of the box
> because they have some runtime dependencies like themes or third
> party
> programs.
> 
> I solved these problems on occasion by making commits such as this: 
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=00c1793ce8e2210e48b18422ea3e76da10541874
> - which adds a wrapper script to "bin/chromium" and includes xdg-
> utils
> in PATH variable.
Including xdg-utils in PATH works, but the preferred solution in Guix
is to use absolute paths where possible.

> It works but it's tedious to do for each and every binary in every
> single package.
You could argue the same about bootstrapping :P

> I see we also have a propagated-inputs field, which looks nice but
> for
> some reason people advice against using it. For what reasons? It is
> not
> as tedious as wrappers and I would really like to be able to specify
> runtime dependencies of packages using it without problems.
Using propagated-inputs is a double-edged sword.  On the surface, it
seems to solve all your problems, but underneath it introduced back all
the dependency shenanigans, that Guix seeks to avoid.  In particular,
you can't upgrade just one of N libraries, that all (indirectly)
propagate the same input.

> I think we must find a solution to this runtime dependencies problem
> that is better than wrapper scripts because they are very tedious to
> create for every single binary in every single package.
Le me presenting an even more tedious solution :)

> Another recent example being that the caja package depends on dconf
> to
> change it's settings, which is not installed by default when users
> use
> window managers like sway.
Shouldn't there already be a library for this?  *sigh*

> Let's find a convenient solution here that would allow us to put an
> end
> to these problems that affect many new users and remains obscure for
> them that they would need to add additional packages in their
> configuration (and which).
We could probably do our best to search for variants of exec in all
kinds of programming languages automatically and then do our
substitute*s with (which "program"), but I personally believe
explicitly doing this is less surprising overall.

Regards,
Leo