Hide Forgot
Description of problem: The old SysV initscript should be package into seperate subpackage when replaced with a native systemd one to avoid confusion amongs end users since systemd will use the native systemd service file when it exist by default thus rendering the old sysv obsolete and keeping it around will only confuse users that for one reason or another are editing the sysv init script. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
... Don't have any of those here.
Also, that's a REALLY BAD idea for making upgrades sane with respect to migrating service state. I'm surprised you think we should do this.
If i'm not mistaken then users need to manually preserve service state. From https://fedoraproject.org/wiki/User:Toshio/Systemd_scriptlet_options # Save the current service runlevel info # User must manually run systemd-sysv-convert --apply httpd # to migrate them to systemd targets so what's the problem with updating with/usr/bin/systemd-sysv-convert --save $service and then remove the old sysv script and have it packed seperatly since, since end users must manually run systemd-sysv-convert --apply $service to migrate the service state? I'm not following your reasoning on why y
Dam enter button I'm not following why your are so surpriced that I suggest we should do this.
(In reply to comment #1) > ... Don't have any of those here. We have /etc/init.d/single which is provided by initscripts And we also have /lib/systemd/system/single.service Which is provided by systemd-units and gets picked up and used by systemd ( which is the reason I filed this bug in the first place ) So what's the plan here between you and Lennart?
(In reply to comment #3) > If i'm not mistaken then users need to manually preserve service state. > > From https://fedoraproject.org/wiki/User:Toshio/Systemd_scriptlet_options Hadn't seen these guidelines yet - that alleviates it somewhat. https://fedorahosted.org/fpc/ticket/31#comment:37 is most of my reasoning - any time a SysV script moves from package A to package B, it greatly complicates the state tracking. Hence, unless you want to explicitly disavow keeping consistent state, it's best to keep it in the same package and deal with the consequences there. With respect to 'single', that's not a service that we support administrator overrides of in SysV, so it's less of a concern with state tracking. I'll move it to -legacy in any case - fixed in git commit b4bdede.