Hi, Am 22.11.2011 13:58, schrieb Stefan Seyfried:
I'm in no way a systemd expert.
not a problem if you know more than I do ;-)
I'm trying to answer your questions with what I know. This might be incomplete or partially wrong, if someone finds an error, please correct me.
On 20.11.2011 22:32, Wolfgang Rosenauer wrote:
The package provides an init script currently and now added systemd service files. So the following questions came to my mind:
Do I still package the sysvinit files? I guess that's a yes because we still offer the sysvinit boot process.
Yes. And obviously if there is a native file, it overrides the SysV init script:
Ok, I revived all the postinstall scriptlets for sysvinit which are obviously still needed.
The package has a sysconfig file which only takes a variable to modify the daemon options. Can I use that for systemd as well? How to do that?
Check the NetworkManager-wait-online.service, it does exactly that:
Thanks for the pointer. Trying that.
The daemon is currently started by default when installed. What happens after the update to the new version which includes systemd files? Will it be enabled by default? (I've actually tried the update and the service was running afterwards so I guess it will be enabled in update case but not for a fresh installation?)
I don't know this one, there was something discussed about the package "systemd-branding" which defines which services to start by default etc, but I don't know if this will apply here.
I know neither. But as I said this makes upgrade in an existing release pretty ugly. Think about tumbleweed or other backports users. That means I cannot create a smooth migration. Unless: Could I just do: systemctl enable pcscd.socket systemctl disable pcscd.service in the %post script?
For the service it makes a lot of sense to use systemd's socket activation feature. So what do I need to do exactly to have the service disabled but have the socket enabled to start the service automatically (in terms of system configuration)? Is the only way to have services/sockets enabled by default to modify some certain systemd package and not from within a package installation? This sounds strange and rather unfortunate so it's for example not possible to install/update a package which then starts a service by default w/o updating an official central distribution package?
I think that your package should be able to supply its own socket file. Udev does it, too:
It does. I was basically wondering how to enable it on upgrades w/o touching base system packages in addition. Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org