On Wed, Jun 12, 2013 at 09:44:16AM -0700, Steve Langasek wrote: > On Wed, Jun 12, 2013 at 04:40:22PM +0800, Chow Loong Jin wrote: > > > Bitrot doesn't happen immediately, and even when it does happen, it will > > take time before its rate reaches an unmanageable state. Plenty of time > > to test a solution in the meantime I say. Basic autogeneration of > > sysvinit and upstart init scripts from systemd unit files perhaps? > > None of upstart jobs, systemd units, and init scripts are homologous to one > another. You can't generate one set from another set without including > additional metadata that's not being used by the "native" system you're > writing for - which means you haven't actually solved the problem of leaving > the users of the other systems with untested implementations. I get that converting between each of these formats perfectly is not possible due to them requiring different fields, but I was thinking that something that made educated guesses might work out in most cases. > For a concrete example, if we assume systemd units are the base and using > socket-based activation as the primary convention, you will have none of the > information here about what events the upstart job should start on; and for > init scripts, you'll have neither this information, nor information about > how to track the processes (pidfiles, etc). Upstart these days has socket activation too. See upstart-socket-bridge(8). As for init scripts, well, er maybe we could use some xinetd-ish helper that handles the starting of socket-activated instead. And I reckon start-stop-daemon could benefit from some of the process tracking code that Upstart uses, which makes the pidfile one less issue to worry about. > Remember that the appeal of upstart jobs or systemd units over init scripts > is that we're removing *unnecessary complexity*. Once you've removed that > complexity, you can't re-synthesize it from thin air in order to > autogenerate init scripts; you have to maintain it somewhere. We could make a best-effort for common cases and require manual intervention for others. Some of the complexity can be inferred and dumped in wherever possible. Other information could be passed in via arguments to the converter. It doesn't always have to operate blindly without the maintainer's help. Anyway, my point is really that there's no use worrying about potential problems to the level of second-guessing what maintainers will or will not do if systemd becomes default. We'll just end up going round and round in circles, but then again I'm sure that's what some people want, as long as we don't switch away from $my_favourite_init, which just happens to be sysvinit at the moment. -- Kind regards, Loong Jin
Attachment:
signature.asc
Description: Digital signature