The prefdm and rc-local services were moved from systemd-units to initscripts with initscripts-9.18-1.fc14, but initscripts does not enable them in %post. There's a wrinkle, here: in system-units the enabling was wrapped in a 'if [ $1 -eq 1 ]; then' statement, but if we do that in initscripts, we'll break upgrades from f13 to f14. initscripts will be being upgraded, not installed, so the if statement won't be satisfied, so the services won't be enabled. There's no immediately obvious solution to this besides enabling the services on every package update, which is inelegant and may be undesired (I can see an admin wanting to disable rc-local). Adding Lennart to CC for his thoughts on how to deal with this. Maybe we should move them back to systemd-units? (this results in fresh installs and f13 to f14 upgrades with this initscripts package not booting to a graphical login, hence urgent). thanks to Michael Schmidt for diagnosing this.
I'm thinking the main error is in systemd design itself. Deciding to "systemctl enable" a service in various %post scriptlets based on whether the package is installed or upgraded is fragile. Once a packager forgets to enable the service in a package, he cannot easily fix it in a later version. The "if [ $1 -eq 1 ]" test is no good. We witnessed this already several times during F-14 development. See the "Heads-up" emails from Lennart on the devel mailing list asking people to fixup their symlinks by a manual action. A good design would easily allow a new version of the package to correct the mistakes of the previous version automatically. Also, the default configuration of symlinks is scattered across packages' scriptlets. There's no way to easily find out, what the default setup is supposed to look like. See a related bug 630174. I propose systemctl should get a new subcommand, let's call it "new-services". Scriptlets would not run "systemctl enable my.service" but "systemctl new-services". This would scan the /lib/systemd/system directory for newly installed *.service and process their "[Install]" sections as the "enable" command would. The difference would be that systemctl would keep a state directory somewhere to track which services were already enabled by it. This will allow to distinguish between services that were never enabled and those that were manually disabled by the user.
that seems reasonable. it's worth considering the behaviour of the previous system here, too. If a SysV service file specifies it should on certain runlevels by default, then when it's installed, it automatically gets enabled; nothing is required to happen in the spec file.
http://git.fedorahosted.org/git/?p=initscripts.git;a=commitdiff;h=f39163514fc1b108c80df1b9b01b63d2d9eafe8d The trick is to not make them enable-able (or disable-able). This works for the case of prefdm, rc-local, etc. which are things that are hardwired to happen. It doesn't solve the larger concern.
Let's discuss the more general concern in bug 630174.
systemd-9-3.fc14,initscripts-9.19-1.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/systemd-9-3.fc14,initscripts-9.19-1.fc14
initscripts-9.19-1.fc14, systemd-9-3.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update initscripts systemd'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/systemd-9-3.fc14,initscripts-9.19-1.fc14
initscripts-9.20-1.fc14, sysvinit-2.87-5.dsf.fc14, systemd-9-3.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update initscripts sysvinit systemd'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/systemd-9-3.fc14,initscripts-9.20-1.fc14,sysvinit-2.87-5.dsf.fc14
systemd-10-1.fc14, initscripts-9.20-1.fc14, sysvinit-2.87-5.dsf.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update systemd initscripts sysvinit'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/systemd-10-1.fc14,initscripts-9.20-1.fc14,sysvinit-2.87-5.dsf.fc14
initscripts-9.20-1.fc14, sysvinit-2.87-5.dsf.fc14, systemd-10-2.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.