Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Legacy SysV initscript file must go into an optional subpackage.|
|Product:||[Fedora] Fedora||Reporter:||Jóhann B. Guðmundsson <johannbg>|
|Component:||at||Assignee:||Marcela Mašláňová <mmaslano>|
|Status:||CLOSED RAWHIDE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Fixed In Version:||at-3.1.12-10.fc16||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2011-07-20 04:42:20 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Jóhann B. Guðmundsson 2011-06-20 06:34:41 EDT
Description of problem: Currently your component is providing both native systemd service files and legacy sysv init script in the same package which is in violation of the packaging guidelines. Once a native systemd service file is shipped and if the intention is to continue to maintain and ship the old sysv initscript the old sysvinit must go into an optional subpackage. "SysV Initscripts Packages may also provide a SysV initscript file, but are not required to do so. This format is considered legacy, but Fedora still contains init mechanisms such as upstart which do not support the systemd unit file format. If present, the SysV initscript(s) must go into an optional subpackage, so as not to confuse sysadmins. The guidelines for SysV initscripts can be found here: Packaging:SysVInitScript" 1.http://fedoraproject.org/wiki/Packaging:Guidelines:Systemd Version-Release number of selected component (if applicable): at-3.1.12-8.fc15 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Comment 1 Jóhann B. Guðmundsson 2011-06-27 07:02:55 EDT
*** Bug 697516 has been marked as a duplicate of this bug. ***
Comment 2 Jóhann B. Guðmundsson 2011-06-27 07:05:51 EDT
Created attachment 510071 [details] Spec file which drops SysV support for atd.service I think this spec file meets the packaging guidelines for systemd note this will drop the sysv init support if you have any intention of continuing to maintain and support the old sysv init script you will need to package that into subpackage as mentioned in the systemd packaging guidelines.
Comment 3 Jóhann B. Guðmundsson 2011-07-15 10:55:00 EDT
What's the current status of you are one of few that is not package native systemd unit in the Base group correctly? If you dont have the time to fix this should I try to find a proven packager to do this for you? https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd https://fedoraproject.org/wiki/Packaging:Tmpfiles.d
Comment 4 Marcela Mašláňová 2011-07-19 12:08:40 EDT
We talked about it on irc, remember? I have finally time to fix it this week, maybe tomorrow. Please don't threaten maintainers with proven packagers. People won't faster co-operate after that.
Comment 5 Jóhann B. Guðmundsson 2011-07-19 12:18:49 EDT
(In reply to comment #4) > We talked about it on irc, remember? I have finally time to fix it this week, > maybe tomorrow. > > Please don't threaten maintainers with proven packagers. People won't faster > co-operate after that. "should I try to find a proven packager to do this for you?" I thought I wrote this more as an offer not a threat but then again I'm not an native English speaker hence...
Comment 6 Marcela Mašláňová 2011-07-20 04:42:20 EDT
I might get the wrong impression from your posts on fedora-devel and in other bugzillas related to sysv initscripts. Also the other reason, why I don't like proven packagers work here, are your patches. Mistake in triggers or scriptlets are sometimes very hard to fix and maintainer has to solve it anyway. I'm non native speaker too...
Comment 7 Jóhann B. Guðmundsson 2011-07-20 05:46:28 EDT
(In reply to comment #6) > I might get the wrong impression from your posts on fedora-devel and in other > bugzillas related to sysv initscripts. Well that's my fail I have a huge character flaw which is that I lack all subtlety in my responces then on top of that you have language barrier misspellings and what not which gives me general fail in human communications. > Also the other reason, why I don't like proven packagers work here, are your > patches. Mistake in triggers or scriptlets are sometimes very hard to fix and > maintainer has to solve it anyway. I'm not a proven packager nor a packager et all so I'm learning things as I go and Toshio Kuratomi which is( and whom I usually ping on irc if an maintainer granted green light on packaging his component), wants me to provide spec files/patches which he reviews and does necessary fixes if needed and commits ( and points to me what i should do better ) to speed things up for him and and or any other other proven packagers that would be doing the work. > I'm non native speaker too...