[Splashy-devel] Bug#619093: Bug#591791: Bug#619093: splashy and systemd: error when trying to install together

Michael Biebl biebl at debian.org
Mon Mar 21 18:30:55 UTC 2011


Hi Steve!

Am 21.03.2011 18:58, schrieb Steve Langasek:
> On Mon, Mar 21, 2011 at 11:30:06AM +0100, Michael Biebl wrote:

> 
> Right, in the policy proposal I am describing that each init script is
> responsible for checking this.  But the actual *implementation* of this
> check can and should use a common shell library to do the heavy lifting.
> Sorry, I didn't think that specifying that belonged in policy.  Do you think
> the use of a common shell library should be enforced in policy as part of
> this?

I do think it would make sense to agree on the name of such a shell library and
at least mention and recommend it in the policy text.
My concern is that if we don't encourage a common shell lib we get all sorts of
inconsistencies and if we need to make adjustments later on (return codes etc)
it's much easier to do it in one place.


>> I'd much prefer if we could use the /lib/lsb/init-functions lib to do the
>> same kind of redirecting for upstart.  That is, all a package needs to do
>> if it ships a native upstart job (or systemd service), is to include .
>> /lib/lsb/init-functions in its sysv init script.  lib/lsb/init-functions
>> /would then do the correct thing, when it is run under
>> systemd or upstart.
> 
>> Steve, do you think this would be an approach that works for upstart (and
>> Ubuntu)?
> 
> I hadn't thought about having /lib/lsb/init-functions automatically do this
> checking when sourced.  I think on some level the idea offends me, the same
> way having C libraries call setuid() or exit() offends me. :)  Also, this
> check is only needed for those packages that *ship* an upstart job, and
> surely those packages know who they are and can handle the conversion easily
> enough if we give them a function to call?

True. The current version of upstart does not (yet) natively support SysV init
scripts, and relies on /etc/init.d/rc to start those services. SysV services in
upstart don't run under the supervision of upstart.
In systemd the situation is a bit different, as SysV init scripts are basically
just another configuration source and we also want to start SysV services under
the supervision of systemd.
I remember though Scott saying though that "native" SysV support was planned in
upstart. So I'm just thinking ahead a bit.
Using /lib/lsb/init-functions has the huge advantage that we already have a
pretty good coverage of SysV init scripts using it (~70 %), which don't need to
be changed to support this redirection scheme.

For upstart with its current features, the shell lib would only redirect the
call to initctl/upstart if if finds a upstart job with the same name as the SysV
init script and would be a nop otherwise.

Regarding the redirection scheme and your loathing of exit, how would you
envision such an interface should look like?

Cheers,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/splashy-devel/attachments/20110321/77238689/attachment.pgp>


More information about the Splashy-devel mailing list