[Pkg-sysvinit-devel] Two line init.d scripts? Sure, that will work!

Helmut Grohne helmut at subdivi.de
Thu Feb 6 12:32:43 UTC 2014

On Thu, Feb 06, 2014 at 11:47:24AM +0100, Petter Reinholdtsen wrote:
> actions on services).  Do I misunderstand how upstart-job work?  If I
> install a package with an upstart job and a symlink to
> /lib/init/upstart-job from /etc/init.d/ on Hurd, will it work?
> Testing...  Nope, did not work:

Thanks for evaluating the methodology on Hurd! I am sure that this is
not caused by a fundamental flaw and would consider your observation to
be a bug in the implementation.

> My idea was to make sure systems based on linux, kfreebsd and hurd
> could keep using the init.d scripts even if upstart, systemd or openrc
> is used by default on Linux, by reducing the maintenance burden for
> package maintainers to keep such scripts working.  Both upstart,
> systemd, openrc, file-rc and sysv-rc are able to start daemons in
> packages providing init.d scripts, and the LSB require such scripts to
> keep working, so we would most likely have that support around until
> we decide to drop LSB support in Debian.

The goal to have a portable interface is venerable and I for one fully
support it. While it is true that currently the LSB init script
interface is the supported method, I do not think that keeping this
support should be a long term goal. We had extensive discussion on this
already and if you read the TC discussion, you'll notice that getting
rid of this interface is among the top reasons for choosing an
alternative. This is why I argue to wrap up one of the contenders and
make it support the old interface reasonably well for some time, before
ditching it entirely.

> Well, I do not add a standard.  I keep the existing LSB standardized
> init.d script standard and make them easier to maintain by reducing
> the amount of information/code each package maintainer need to provide.

Essentially you are. Similarly you could argue that cdbs was not a
standard for Debian packages. Your helper creates a layer that needs to
be understood to interface with it. This is kind of a gray area, so I
would rather not oppose your solution if it turns out to work well. Good
luck with that!

> > Why not write an upstart job instead? It works with sysvinit today!
> Because it only work with upstart at the moment. :)

Point taken. I still think that this is a limitation of the current
packaging rather than a fundamental one. If one assumes that the TC
decides in favour of upstart, this would be one of the first things to
fix in order to be able to drop init scripts in favour of job
descriptions. I am making no claims about the actual result though.


More information about the Pkg-sysvinit-devel mailing list