On 2016-11-21.08:11, The Wanderer wrote: > On 2016-11-21 at 07:56, Vincent Bernat wrote: > > > ❦ 21 novembre 2016 23:39 +1100, Scott Leggett <sc...@sl.id.au> : > >> I personally cannot test such init scripts since all my systems now > >> use systemd, and I can't in good faith include code that I can't > >> test and which has known bugs. > > (That's an interesting usage; I would have used "good conscience". I'll > have to keep an eye out for this one.) >
Perhaps that's what I meant.. you're probably right :)
> >> If there is another approach you think I could take here, please
> >> advise...
> >
> > People who want other people to keep init scripts alive are asking
> > to just leave them be, even if they are buggy. That's not something I
> > agree with, so I am happy that you just removed them. But you could
> > get some opposition.
>
> My own position is roughly that init scripts should be left in place
> unless the maintainer sincerely believes that they are not just buggy,
> but so badly broken that either they provide no functionality at all, or
> to have the functionality which they provide is _worse_ than to not have it.
>
> In other words: do you, as the package maintainer, believe that a
> reasonable person would prefer having no init-system functionality for
> this package at all over having what these init scripts provide?
>
I think quagga is a bit of a special case in this regard:
The Debian package uses a Debian-specific "quagga" init script which
takes subcommand arguments to the usual start/stop/restart for managing
the multiple routing daemons. It also implements a priority system where
groups of daemons can be stopped and started with one command. All of
this init script behaviour is configured using two configuration files -
/etc/quagga/{debian.conf,daemons}. Yes, two configuration files to
configure the behaviour of this one init script _in addition_ to the
rather more common /etc/default/quagga.
Needless to say this complexity is inconsistent any other daemon within
Debian and with upstream (which implements a single init/service per
routing daemon rather than one that controls them all). It's also rather
error prone as illustrated by the number of bugs closed by switching to
systemd.
The fact that the init script is monolithic also leads to problems when
trying to keep it along with the new .service files because there is no
equivalent quagga.service. To keep /etc/init.d/quagga, I'd have to mask
quagga.service in systemd, but that can always be unmasked by the
administrator and cause issues with multiple services trying to start
the same daemons.
If all that wasn't enough, upstream also ship a "watchquagga" service
whose sole purpose is to do the job that systemd now does for all
daemons - restart services when they crash or hang. With systemd,
"watchquagga" can be removed completely.
I hope this doesn't come across as too critical of the existing init
scripts - they've clearly served their purpose well. I just think that
there's a better option now.
So my answer is: I believe that a reasonable person coming to quagga for
the first time would rather have an interface consistent with all their
other services, instead of having to learn the intricacies and quirks
specific to the quagga init scripts. However that person will have very
different perspective to the Debian old-timer who was running quagga for
a decade using the existing system and now has to learn something new
(new, but consistent with every other service in a default Debian
installation).
As I said before, I'm open to keeping the existing init scripts. But
only if a) someone else steps up to do the testing and ongoing
maintenance of them, and b) the experience under systemd is not
diminished.
--
Regards,
Scott.
signature.asc
Description: Digital signature
