Created attachment 433786 [details] Native systemd file for pcscd Description of problem: The attached file is a native systemd file for upcoming F14 Feature [1] Please read [2] on how to installing systemd Service files. 1.http://fedoraproject.org/wiki/Features/systemd 2.https://fedoraproject.org/wiki/User:Johannbg/QA/Systemd/Daemon#Installing_Systemd_Service_Files If you have any question dont hesitate to ask them on this bug report. Thank you. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle. Changing version to '14'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
ping
I'd like to see the Packaging Committee discuss systemd unit file packaging before we start including them in packages. The link [2] in comment #1 is probably a good starting point for official guidelines. However, as far as I can tell nobody has proposed any new systemd-related guidelines to the Packaging Committee so far.
Well, so far this is all optional. You are free to skip this for now, and I won't even be grumpy. ;-) Would be cool though if you could ship this. BTW, it is not sufficient to just drop the .service files into /lib/systemd/system. It is also necessary to enable it when upgrading from an old sysv-only rpm. How to implement that in the spec file with minimal work is documented in daemon(7): http://0pointer.de/public/systemd-man/daemon.html#id2562029
Moving systemd service RFEs to rawhide. At this point, it is not appropriate in the Fedora 15 cycle to add these. Furthermore, at this point, we are still finalizing the packaging guidelines to handle SysV -> systemd upgrades. We therefore request: - wait until there are packaging guidelines (this will be announced on the devel list). This ensures that upgrades will work smoothly and we/you won't have to do multiple sets of changes. - work on these sorts of changes for Fedora 16 where necessary, not Fedora 15, as we're trying to fix things for release. - do *not* change a service from SysV to systemd in an existing release (such as Fedora 15), as this is the sort of behavior change that goes against our update policy, documented as https://fedoraproject.org/wiki/Updates_Policy
What's the current status on this and note as per packaging guidelines the old sysv init script would be packed in a separate subpackage if the intention is to continue to maintain and support. 1.https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd
I have local modifications to pcscd for systemd socket activation, but I haven't submitted these upstream yet. And no, I don't think there is any point in shipping the sysv init script in a separate subpackage.
Created attachment 509688 [details] Spec file which introduce systemd unit file and drop SysV support for pcscd.service I threw in here a spec file which introduce systemd unit file and drop SysV support for the submitted pcscd.service encase your changes dont make it in, in time for alpha so we dont end up blocking the alpha release you can then update the service file with the socket one and introduce a smartcard.target if you went into that direction.
Thanks Jóhann. I took a quick look at your changes and it would appear that they are missing the %triggerun part for cleaning up after sysv init script removal (systemd-sysv-convert and chkconfig --del): http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Packages_migrating_to_a_systemd_unit_file_from_a_SysV_initscript Also note that pcscd is NOT on the Live CD, so it would not be a blocker for the Alpha release.
Ah you are correct I missed the upgrade path although it's debatable how useful that is since the end user still needs to enable the service after upgrade "When updating from a package containing a SysV initscript to a package containing a systemd unit file, we "start-over fresh" with default start and stop policy from the new package, and do not migrate what the user had previously configured." so whether the user runs systemd-sysv-convert --apply foo or systemctl enable foo.service makes no difference I would think. Ah somehow I took it for granted that pcsc-lite was installed by default on the Live cd regardless of that the sooner we get a native service file in rawhide the better. ;)
I just submitted the patches and unit files upstream: http://archives.neohapsis.com/archives/dev/muscle/2011-q2/0138.html
Just out of curiosity is this service applicant for hardware activation unfortunately our guidelines are a bit short on how to do that "Hardware activation Hardware activation occurs when a service is installed but only turns on if a certain type of hardware is installed. Enabling of the service is normally done with a udev rule. At this time we do not have further guidance on how to write those udev rules. The service itself installs its .service files in the normal places and are installed by the normal systemd scriptlets. These services should never be enabled by the package as they will be enabled by udev. " But you can read man systemd.device and look at the bluetooth service which is doing that I believe if it's relevant..
Yes, hardware activation would be nice to have.
I just built pcsc-lite-1.7.4-2.fc16 for rawhide with the systemd patches applied and dropped the sysv init script. Thanks for all your help, Jóhann!