Re: Some suggestions on old-fashioned usage with s6 2.10.x

["Laurent Bercot" <ska-supervision@skarnet.org>]

>I did not actively follow the recent evolution of s6, and have just been
>bitten badly by s6 2.10.x on my Alpine servers (where slew [1] is used
>of course) when it comes along with other updates.

  Sorry. This bears repeating: major version upgrades may break things.

  Compatibility is a good thing, that's why I try to keep major version
changes few and far between; but the other side of the coin is that
when I'm doing one, I want to make use of it and cram all the
incompatible changes that may be needed in the foreseeable future.
  So, you have to pay attention less often, but when it happens, you do
have to pay attention. Previous major version changes may have gone
smoothly - I try to keep it as smooth as possible when there's no need
to break UX - but it's no guarantee that it will always be smooth
sailing. This time, there were very visible user changes; sorry for
the inconvenience, but I reserve the right to do this, and I try to
document the breaking changes in the release notes.

  It is, admittedly, a drawback of distributions that they make major
version upgrades very silent - so, if you have local software that
relies on an old API, and the distro updates it under your feet,
you're caught unaware. I don't have a satisfying solution to this;
maybe I should have added a post-upgrade file printing red blinking
bold text, but that doesn't address automated or afk updates.


>better if we kept the option supported for a transition period, and that
>only removed it from the manual pages while urging users to get rid of
>it.  After all, in this case, silently ignoring `-s' is behaviourly
>similar to (if not perfectly compatible with) old `s6-svscan'.

  It's always a delicate balance, because "better" is not 
one-dimensional.
It would be better UX, yes, definitely. But also legacy code to maintain
until the next major update (which can take a while), and I tend to
assign a *very* high cost to legacy code in s6-svscan and s6-supervise,
for obvious reasons. And in my experience, few people (and you,
Casper, certainly belong to them!) actually bother changing their
scripts as long as they keep working - most only spring into action when
something breaks. A compromise I've found relatively efficient was to
add nagging warnings on deprecated option use, but 1. that's even more
code that will be removed, and 2. I hate nagware, with a passion, in
all its forms.
  There is no really good solution, and I prefer a short, sharp pain
(when things break) followed by relief (when they're fixed) to a long
dull ache (maintaining compat code). Especially when I'm not the one
experiencing the sharp pain ;)


>Second, `s6-svscan' now waits for its `s6-supervise' children to exit
>before exec()ing `.s6-svscan/finish'

  You seem to have found the proper way of managing this with SIG files,
but just in case: "s6-svscanctl -tb" will net you the old behaviour.

--
  Laurent