[2019-08-21 16:56] Lorenz <lorenzo.r...@gmail.com> > >> 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.