#359 Guideline: Forbid sysv initscripts in addition to systemd unit files
Closed: Fixed None Opened 5 years ago by bochecha.

Unless I'm mistaken, no current Fedora release ship upstart of sysvinit any more. (at least upstart was retired during the Fedora 18 development cycle)

That means that right now, in Fedora, there is nothing left that will use sysv init scripts if there also is a .service file (as systemd will ignore the former if it finds the latter).

The current guidelines allow it, but the relevant part was written at a time where we still had at least upstart in the distribution.

Therefore, I propose that [https://fedoraproject.org/wiki/Packaging:SysVInitScript#Initscripts_in_addition_to_systemd_unit_files the following]:

{{{
=== Initscripts in addition to systemd unit files ===
{{admon/note||If your package has not yet migrated to systemd unit files, or is targeted for a Fedora release older than 15, follow the guidance in [[Packaging:SysVInitScript#InitscriptScriptlets]] instead.}}

In Fedora 15+, SysV initscripts are no longer the default, they have been obsoleted by systemd unit files. There are guidelines for systemd here: [[Packaging:Systemd]].

However, packagers who wish to include SysV initscripts may also do so, but they MUST be placed into a separate $name-sysvinit subpackage. Please note that the base package MUST contain the systemd unit file. In this scenario, use the following scriptlet:

%triggerpost -n packagename-sysvinit -- packagename < 1.0-2
/sbin/chkconfig --add packagename >/dev/null 2>&1 || :

Please note that in the example, "1.0-2" is the version in which the package switched to systemd unit files by default.
}}}

... be changed to something like:

{{{
=== Initscripts in addition to systemd unit files ===
{{admon/note||If your package has not yet migrated to systemd unit files, or is targeted for a Fedora release older than 15, follow the guidance in [[Packaging:SysVInitScript#InitscriptScriptlets]] instead.}}

In Fedora 15+, SysV initscripts are no longer the default, they have been obsoleted by systemd unit files. There are guidelines for systemd here: [[Packaging:Systemd]].

Packagers MUST NOT include SysV initscripts in addition to systemd unit files, even in a separate $name-sysvinit subpackage.
}}}


I'm ok with explicitly disallowing Fedora binary RPMs to contain SysV init scripts, but I hope we can still use dist tags to conditionally ship them for EPEL 5 and 6.

Replying to [comment:1 ktdreyer]:

I'm ok with explicitly disallowing Fedora binary RPMs to contain SysV init scripts, but I hope we can still use dist tags to conditionally ship them for EPEL 5 and 6.

Right, what I'm asking for is only for the Fedora branches, and I'm certainly not asking for a guideline removing the right to use conditionals for EPEL. :-)

Sorry if I wasn't clear, and thanks for making that explicit.

At last week's meeting we discussed this but failed to achieve quorum on either of two votes:

The first was basically:

Ban Sysvinit scripts in new packages (for Fedora. EPEL would be able to have them via conditionals). We didn't have a formal vote but we leaned towards

  • +4, remi|Fedora, geppetto, tibbs, limburgher
  • -1, abadger1999

The deciding factor wasn't about whether there was anything in Fedora to make use of the scripts but whether having the scripts would cause issues for packages that already had systemd unit files. Remi|Fedora brought up that having an init script with Provides: $name-same-as-systemd-unit currently means that systemctl start $name-same-as-systemd-unit will start the initscript. https://bugzilla.redhat.com/show_bug.cgi?id=1012462

Some problems with the example, though:

  • Seems like a systemd bug. It needs to be reported to find out if systemd will just fix that behaviour
  • That's a collision between two packages -- the httpd package provides a unit file. the boa package was providing a sysvinit script. You could achieve the same thing with just unit files if boa shipped a unit file in a different systemd directory that wanted the httpd name.

Proposal was also made to simply make even clearer that sysv init scripts shouldn't be shipped unless there's some maintainer need for them:

Proposal: add this to the page "As of Fedora 19 there are no init systems in Fedora that do not understand systemd unit files. Unless you have a need for the subpackage yourself you should not be creating sysvinit subpackages."

This got (+1:2 [geppetto, abadger1999], 0:0, -1:0) as we had a netsplit that prevented further voting.

If people would like to continue voting on this ticket, we could close this out. Voting for both proposals would be fine -- If the first one passes, it would override the second (as we'll be getting rid of the whole section.) (People probably should revote for proposal #1 as our vote for that at the meeting wasn't very formal.)

At today's meeting, banning was approved:

info "Packagers MUST NOT include SysV initscripts in addition to systemd unit files, even in a separate $name-sysvinit subpackage." Approved (+1:5, 0:0, -1:1)

It was noted that what effect this should have on already approved packages should be made in this case. When I write this up, we'll include this in the announcement to address that: "as in many cases of guideline changes, old packages are grandfathered but packagers are encouraged to look into dropping the sysvinit subpackages as they update in rawhide"

Written up:

https://fedoraproject.org/wiki/Packaging:SysVInitScript#Initscripts_in_addition_to_systemd_unit_files

Announcement text:

"""

The guidelines for including both sysvinit scripts and systemd unit files were changed. New packages must not include both even if the sysvinit scripts are in a separate subpackage. As in many cases of guideline changes, old packages are grandfathered but packagers are encouraged to look into dropping the sysvinit subpackages as they update in rawhide.
https://fedoraproject.org/wiki/Packaging:SysVInitScript#Initscripts_in_addition_to_systemd_unit_files

"""

Metadata Update from @bochecha:
- Issue assigned to toshio

2 years ago

Login to comment on this ticket.

Metadata