[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Specify runtime dependencies with propagated-inputs or wrapper scrip
Re: Specify runtime dependencies with propagated-inputs or wrapper scripts
Fri, 26 Mar 2021 22:56:45 +0100
On Fri, 2021-03-26 at 20:36 +0100, Léo Le Bouter wrote:
> 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
> I solved these problems on occasion by making commits such as this:
> - which adds a wrapper script to "bin/chromium" and includes xdg-utils
> in PATH variable.
> It works but it's tedious to do for each and every binary in every
> single package.
> I see we also have a propagated-inputs field, which looks nice but for
> some reason people advice against using it. For what reasons?
One reason is incompatibility.
Try "guix environment --ad-hoc pidgin eom", it will fail.
(At least, it used to, due to both gtk+@2 and gtk+@3 being in a
single profile, or perhaps I got the package names wrong.)
Another reason is that you lose ‘scoping’ (not sure how to name this).
Consider each project to be like a Scheme module (M). (M) can export
(define do-stuff ...)
(define search-kitties ...)
("surf" "In the beginning, there were kitties")))
[some library for adopting kittens]
Assume there is a module (puppies) as well, that also
has a "surf" binary. Now consider an adoption centre application
(animal-adopt), that uses the "surf" binaries from both (kitties)
and (puppies) for finding kitties and puppies. In Scheme-land,
this works just fine, without ambiguity:
(call-binary "surf" #:module '(kitties))
(call-binary "surf" #:module '(puppies))
However, this won't work if all binaries were in a single, global
hash table, instead of being defined per-module (or package in Guix-speak).
How could "animal-adopt" use both "kitties" and "puppies" if it were
to add "kitties" and "puppies" to propagated-inputs? Also, if
"animal-adopt" only has "kitties" as propagated-input, how could
a user install both "animal-adopt" and "a-browser-simply-named-surf" in their
> 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.
> 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.
This seems a difficult problem.
> 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.
> 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).
In order to discover these kind of issues earlier, it would be interesting
to create a "ambient-trouble" package, that has binaries named after
the common culprits "xdg-config", "which", "cat" (for shell scripts actually
requiring "coreutils"), maybe some others, to be used like this:
$ guix environment --ad-hoc software-to-test ambient-trouble
$ AMBIENT_TROUBLE_LOG=$HOME/ambient-trouble.log software-to-test
The fake "xdg-config", "which", "cat" ... would then write a line
to $AMBIENT_TROUBLE_LOG and return 1 (failure). In the package guidelines
we could recommend testing with "ambient-trouble". To find out current
violations, ‘someone’ could install "ambient-trouble" in their profile
and see what breaks.
Now I think of it, it should be sufficient to test with
"guix environment --pure", but it clears out too many variables
(e.g. DISPLAY is not unset, but XAUTHORITY is --- see
%precious-variables in guix/scripts/environment.scm).
Is there any reason why XAUTHORITY is unset but DISPLAY isn't?
After all, "guix environment --pure" is not that pure that it
removes process persona, removes the reference to the root & current
working directory from the process ... I don't see why keeping the
reference to the display server accessible would be any different from
keeping standard input/output/error open.
It's all I/O, the only (conceptual) difference is in representation
(text/bytes or pixels).
Description: This is a digitally signed message part