[2019-08-21 16:56] Lorenz <[email protected]>
> >> if test ! -h "$svdir"/supervise; then
> >> rm -rf "$svdir"/supervise
> >> - ln -s /var/lib/runit/supervise/"$sv" "$svdir"/supervise
> >> + ln -s /run/runit/supervise/"$sv" "$svdir"/supervise
> >
> >Will it handle both /var/lib and /run/runit location?
>
> Mmm.. No
> In my system i have a mix of
> * supervise inside /etc/sv/foo that is not a symlink ( due to my own
> experiment i believe)
> * supervise that is a symlink to /var/lib/runit/supervise/foo (current
> dh-runit)
> * supervise that is a symlink to /var/lib/supervise/foo (update-service
> before dh-runit)
>
> if you prefer i can force a replace of /var/ with /run each time one types
> 'update-service --add /etc/sv/foo'
I do not have opinion on that, since I do not use 'update-service'.
> new patch attached should handle all of the above cases, except it
> won't replace a supervise dir of an already running service (of
> course)
Nice, thank you.
> About this, I forsee trouble during an upgrade of a package that already
> ship a runscript, think of the following
> [...]
>
> I can test the opposite (switch from /run into /var) and it doesn't
> end up good
>
> [...]
> Looks an acpid process managed by runsv survives but i can't send signal to
> it!
I see and more or less, understand why it happens. What about making
in postinst symlink
/run/runit/supervise/foo -> /lib/runit/supervise/foo
if latter exists? It should resolve problem with overwriting symlink of
running process.
> Maybe let runit-helper create the symlinks rather than shipping in the
> package itself is a more flexible approach?
Maybe, but I hope to avoid it. Testing maintainer scripts is pain,
making sure files created by maintainer scripts are correctly
updated/purged is pain.
I want `runit-helper' getting small and trivial, not big and
complicated.
--
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.
