On Fri, 22.08.14 15:51, Colin Guthrie (gm...@colin.guthr.ie) wrote: > Hi, > > I recently changed my %post scripts in Mageia to use systemctl preset > rather than systemctl enable to allow for policy-based overrides of > "enable on install" behaviour. > > Sadly, unlike enable, preset does not shell out to chkconfig, so passing > a service name that's not got a native unit no longer gets enabled. > > Now I can work around this in our %post scripts, but an alternative > would be to teach preset about chkconfig and shell out to that if a > native unit is not found. > > I'm not overly bothered where I work around this and of course long term > goal is not to ship any sysvinit scripts anyway. But before I work on a > solution, would upstream be interested in preset supporting chkconfig? > > If not, it's probably quicker and easier for me to do the work and > maintain it in scripts rather than systemctl itself, hence why I figured > I'd ask first.
Currently the compat support for chkconfig is nicely hidden in systemctl on the client side, and doesn't spill into the backend code on the server side. Forking off chkconfig from PID 1 sounds like something I'd be very cool about... Generally we have the rule of not extending compat features beyond what they did in the implementation we try to be compatible with. In this case this would probably mean that presets weren't available in chkconfig, and hence they won't be available when chkconfig is invoked via systemctl... I am not entirely sure I get the usecase here. If you invoke this from an RPM scriptlet, then you apparently make the package systemd-aware. But if you do, then why not also write a systemd unit file? I mean, it sounds weird doing one but not the other? What's the rationale here? Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
