On Fri, 23 Dec 2016 12:52:41 +0800 Scott Leggett <sc...@sl.id.au> wrote:
> On 2016-12-22.11:18, Rui Ribeiro wrote:
> > It is sad people discontinuing functionalities that server a
community and
> > have been working for so many years.
> >
> > I will starting doing my own debs, and will migrate in short time to
> > FreeBSD.
Well, I have no intention of moving to FreeBSD, but I agree completely
that what is
happening here is silly (to say the least).
> I understand your position but I do not run any SysV Debian systems
> myself so I am unable to properly debug, test and maintain SysV scripts
> with known bugs.
Well, then let the ones that do send in patches and bugfixes. Anything
would have been
better than blatantly removing the /etc/init.d/quagga script.
> If you or anyone else who uses SysV would like to help with the quagga
> package in Debian by testing and maintaining such scripts, they would be
> very welcome.
I'm going to write a script right now and send it in as a patch. As
soon as I do, can you
make sure it ends up in Debian stable?
> I think the way to do that would be to form a quagga
> maintenance team. Let me know if you are interested.
What's wrong with simply sending in patches to the existing maintainer?
On another note:
Upon examining the "systemd support" of the package, I find them riddled
with
violations of UNIX' prime directives:
- Thou shalt not chown/chmod pre-existing (config)files of an already
installed package.
You can do that, once, in the installation scripts. This should never
be done whenever
a daemon is started or stopped.
Doing so, like in these scripts, violates the principle of
least-surprise to sysadmins, and hence
introduces subtle but pervasive security and operating risks.
The assumption should normally be that the sysadmin maintaining the
system is competent.
Hence daemons shall not override ownership and permission settings on
files and must assume that
the sysadmin knows what he is doing.
The only things you could do are either:
- Log a warning and proceed anyway.
- Log an error and abort the daemon.
- Log a warning and proceed but disable certain features because of
increased security risks.
If the startup scripts actually chown/chmod every time the daemon
starts, then that implies that you
assume that the sysadmin administering the system is incompetent to
begin with.
Seems like the wrong starting point (to me at least).
