Replies: 2 comments
-
tracking PR #782 |
Beta Was this translation helpful? Give feedback.
0 replies
-
Hi, this seems needed indeed, see: https://lists.alpinelinux.org/~alpine/users/%3CaEGb5j6aR8tEKWz6%40falared%3E |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
to ease writing init scripts that depend on environments from other services, ideally we'd have a way for scripts and users to set variables that would be automatically exported to some value.
current design i have in mind includes two new features, a new
env
action fordepend()
, and a newenv
command forrc-update
.the depend keyword would write a new service option env, so we'd end up with
/run/openrc/options/$RC_SVCNAME/env
. only the activation environments of services you depend on would be exported.the rc-update command would instead append
/run/openrc/env
, which would be loaded by all services unconditionallyso, as an example, dbus' script could be have:
conf.d/dbus
init.d/dbus
depend() { env DBUS_SESSION_BUS_ADDRESS }
then any service doing
depend() { need dbus; }
would automatically get the variable in their env.likewise, a user could in their wayland compositor configuration, do:
considerations:
currently we have no sort of activation environment, but we filter the environment variables from the process calling us, with
rc_env_allow
inrc.conf
. should we automatically export such allowed variables to the activation env? currently the wayland example works fine without needing anyenv
command by just allowing the display variable.runlevel specific env files?
Beta Was this translation helpful? Give feedback.
All reactions