Red Hat Bugzilla – Bug 714642
Legacy SysV initscript file must go into an optional subpackage.
Last modified: 2011-07-20 05:46:28 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.
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"
Version-Release number of selected component (if applicable):
Steps to Reproduce:
*** Bug 697516 has been marked as a duplicate of this bug. ***
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.
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?
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.
(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...
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...
(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...