Hi, Gergely Nagy: > > Oh except that some people didn't, which causes problems for the systemd > > transition -- because init skript that are not skeleton-based don't know > > how to redirect itself to systemd … > > Err, no. I have plenty of sysvinit scripts that work just fine with > systemd, and are not at all based on skeleton. > Note I said "redirect to systemd", not just "works with systemd". Or s#based on skeleton#uses /lib/lsb/init-functions# if you did not miss that. > Even if you generate an init script from systemd service files, the end > result will be terrible, on the same level as the current sysvinit > situation is. The result will either be exactly equivalent to a mostly-unmodified skeleton script, which in many cases is an improvement, or die because of unsupported service file stanzas. In any case, I'd rather have an autogenerated init script and an uptodate service file, than a somewhat-out-of-date sysvrc script which systemd runs in compatibility mode and no systemd service file. I'd like the common maintainer of the common daemon-providing package to be able to get by with maintaining _one_ config file for said daemon which s|he can actually test … Finally, we don't *know* that > the end result will be terrible unless somebody actually tries to do this. > There's a reason it has not been done neither for upstart, > nor for systemd: it's not worth it. > systemd is already declarative and runs sysv-rc scripts, so the cases are not equivalent. -- -- Matthias Urlichs
Attachment:
signature.asc
Description: Digital signature