On Wed, 27.05.15 15:26, Martin Pitt (martin.p...@ubuntu.com) wrote:
> Lennart Poettering [2015-05-27 15:18 +0200]:
> > If we do this, then I'd like to go all the way right-away: strip
> > chkconfig support if we add support for the new hook.
>
> OK.
>
> > > + if (!isempty(arg_root) && !streq(arg_root, "/")) {
> > > + log_error("Can not %s SysV init script when a
> > > root directory other than / is specified", verb);
> > > + continue;
> > > + }
> >
> > Hmm, this makes me feel a bit uneasy about the LSB support... If
> > neither "is-enabled" nor "--root=" can covered by the LSB tool, I
> > wonder if we should use it at all...
>
> You give it the full path, so we could also just invoke it with
> path_join(arg_root, p).
That sounds wrong, as that might result in symlinks created in
/etc/rc.d rather that $(root)/etc/rc.d, if you follow what I
mean... Moreover, the symlinks might end up pointing to absolute paths
including the $root prefix, and that would even be worse...
It really matters to pass the root prefix as such to the tool instead
of simply prefixing it to the init script...
> As for is-enabled, since that doesn't exist anywhere we could try and
> call /usr/lib/lsb/initd_enabled.
We really shouldn't place this in the LSB namespace if we aren't LSB.
> > Also, as it appears the LSB tool only takes a single script per
> > invocation, which is also incompatible with how we need it...
>
> I didn't see that being used anywhere in the systemd source, did I
> miss anything? If so, you can always call stuff in a loop instead,
> no?
Sure, but I think the hook should provide for this natively, instead
of us emulating things around it... But dunno, this certainly isn't a
major issue...
>
> > Maybe introducing a new tool for this that covers all options is the
> > better idea. Let's call it /usr/lib/systemd/systemd-sysv-install or
> > so, taking the --root= switch as before, plus "enable", "disable",
> > "is-enabled" plus one or more LSB init script names is the better
> > option... Distros implementing LSB can then direct this tool to the
> > LSB tools if they wish, and Fedora can translate this to chkconfig,
> > without losing any functionality...
>
> I kinda like adhering to LSB, at least where it makes sense; obviously
> we don't have a specification for is-enabled, so we have to make up
> one (/usr/lib/lsb/initd_enabled), but for enable/disable it seems
> quite fine?
Well, again, it covers neither --root=, nor is-enabled, and we
shouldn't pollute foreign namespaces like this.
I mean, you can try to get both the --root= and the is-enabled thing
into LSB proper, but that would take ages, of course... (is the LSB
process even still alive?)
Extending the LSB definitions one-sided and stepping into their
namespace is something we really should not do. There's no point in
having namespaces at all if we ignore them and step into them
anyway...
> But if you still say you want /usr/lib/systemd/systemd-sysv-install
> I'll implement it that way. I care more about getting some abstraction
> than getting an LSB compatible one :-)
I think I would prefer that.
Lennart
--
Lennart Poettering, Red Hat
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
