= Proposal topic =
Converting from systemVinit to systemd unit files causes system administrators to have to evaluate whether a service is set to run or not according to their local policies. Attempting a strategy to convert all services to unit files within a single release would cause the least pain for sysadmins.
= Overview =
== Problem space ==
When a service converts from a systemVinit script to systemd unit files the service resets to the default enabled state from the unit files. This is somewhat inconvenient for system administrators as they'll have to examine their systems after such an upgrade to tell if they need to reconfigure on-boot on/off state.
For this reason, the FPC guidelines specify that services are not allowed to switch from sysv to systemd over the course of a distro release (in addition to the other potential mishaps that may occur). By placing transitions at distro upgrade, system administrators are at least given a warning that the upgrade may require extra vigilance post-upgrade. However, FPC also noted that this is also not ideal as it means that system administrators would need to get used to checking the on-boot enable/disable state of their services on every distro update. It would be much better if there was only a single distro update where this was a problem. Future distro updates would just work.
= Solution Overview =
There are a pair of options open to us for creating an environment where all startup is transitioned in a single release:
A third option is to accept that system administrators will have to check the on-boot status of services after every distro upgrade and try to mitigate the impact of this (for instance, documenting all of the services that converted for this release so system administrators can scan the list and take a look at any services that they have installed).
== Option: Blocking release == This option has the least drawbacks for system administrators but the highest amount of work for us to perform during this release cycle. System administrators would only have to check for changes in on-boot enablement for one release. We would have the burden of converting all services this release or slipping our schedule.
This option has already been partially adopted as we're planning to block alpha release for unconverted services on the livecd. Extending the set to all services on handout media (meaning to expand to include services on the DVD) with a deadline later than alpha has buy in from Viking-Ice as a good strategy. Viking-Ice estimates that @core, @base, and livecd cover most of the non-trivial to convert cases; remaining services should be about 15 minutes per service to convert. However, there is no estimate of total time required at this point.
Even if we choose to go with Option 3, converting over the course of several releases, this may be a viable option for the last release that we want to be performing conversion within. (ie: forcing conversion at some point rather than merely documenting what packages maintainers have chosen to convert within a release)
== Option 2: Block Unconverted Services ==
Under this option, we'd block unconverted services from the yum repositories. When such services were converted they would be re-added to the repositories. Likely we'd couple this with blocking the release itself for essential services (livecd at this time; if approved, expanded to services on handout media)
This strategy is not as clear cut a win as Option 1.
Pros: it allows services to be converted to systemd unit files over the course of a release (they're treated as new services). It provides an incentive for package maintainers to convert to systemd without blocking the release. Users who upgrade will know that the services they're updating when they update their system will need to be examined. Services which are not updated should be removed until an updated package becomes available in Fedora.
Cons: We may lose some services for F16 due to not being ported. Some services which are not in F16 but in F15 will stop working as dependencies are updated during the upgrade that break the service. Yum upgrades may require the user to explicitly yum erase the services that are not present. Other services will continue to work but when the packager does update the service to have a systemd unit file, the system administrators will need to check whether that service now is enabled on-boot or not according to their preferences (mid-release).
== Recommendation ==
After writing the pros and cons, I'd recommend against Option 2. I would recommend something as close to Option 1 as we can manage. If a pure Option 1 is not deemed possible for F16, then I'd recommend that:
= Active Ingredients =
All packagers of services.
provenpackagers and FES people who can work on porting services and applying the changes to packages where the maintainers are unresponsive to the changes.
Viking-Ice, michalp, others involved in systemv=>systemd porting.
QA to add "all services ported to systemd unit files" as a blocker for release (be it F16 or F17).
FESCo to make the decision.
= Owners =
For now toshio but he'll defer to Viking-Ice in nearly all respects.
From 2011-07-25 FESCo meeting: * need to get audidt #617321 iscsi #714688 NFS-Utils #699040 Tigervnc #717227 dnsmasq #694932 openvpn #714710 speech-dispatcherd #697600 smolt #697612 wpa_supplicant #661230 done before next tuesday if at all possible. * AGREED: continue working on conversion, prioritizing services on livecd/livedvd, and services that start by default. Viking-Ice will organize activity days around conversion. revisit status next week * current status at https://fedoraproject.org/wiki/User:Johannbg/Features/SysVtoSystemd * ACTION: Viking-Ice will organize activity day around service conversion
We decided not blocking alpha because of non-finished: NFS-Utils #699040, dnsmasq #694932, wpa_supplicant #661230
ACTION: get back to Viking-Ice's activity day
Replying to [comment:4 mmaslano]:
So far the most "effective" converting motivator has been if the relevant maintainers component is set to block the release and I'm pretty sure maintainers will just continue to ignore it if fesco actually is not going to block the release..
As I explained here there is absolutly no purpose in holding a FAD day for the remaining services. ( +I had to host an whole archery tournament from thursday to this monday evening and will be busy tomorrow morning taking down the track )
http://lists.fedoraproject.org/pipermail/devel/2011-July/154919.html
If fesco has any serious intention in meeting the approved set alpha "goals" regarding the systemd unit it can walk through that list and package it themselves or get someone with proven package to do it for them however if fesco is planning on allowing the convertion process to be dragged through several release cycles then by all means say so so I can drop the feature and save myself some time in the process.
Thanks.
JBG
Should we/could we force rejection of packages that still were not converted from sysv to native systemd units out of Fedora some time during F19 development?
Maintainers that have not migrated at this point simply dont care or dont want too and sometimes these things just take time and why is F19 suddenly gone more urgent than <F18 mean why can we now result to "extreme actions" while we could not do that earlier?
+I'm not seeing that you can block or reject around 150 components just like that...
And on top of the unmigrated legacy sysv service files we need to revisit the around 600 components once all of them have been migrated and cleanup the spec files add "preset" to them, patch those unit to reflect the current state of systemd and make decision if we really want to continue to use /etc/sysconfig/foo environment files. Even to go so far as deciding if we still require systemd to be backwards compatible with legacy sysv init files since we would have migrated anything we ship in the release.
And once all the above is done we probably should look into revising daemon startup of DE and or default install ( arguably no need for rsyslog,atd,cron etc since up to certain extent those functionality come with systemd ),get rid of those fedora* services and patching all startup daemons in a full blown desktop to be socket activated ( where applicable ) to get the boot time down to at least 10s by default on ssd or rotating media.
Default Gnome+Libreoffice installation of F18 TC2 with btrfs partition on ssd which I just did of the DVD, takes 41s to startup ( networkmanager-wait-online service being the culprit here ) after tweaks without loosing any desktop functionality it can be shaved down to around 2.5s on ssd and around 10s on rotating media so as you can see there is plethora of room for us to improvement here ( some of which should just come with upstream changes to us in F19/F20 timeframe ).
we have just finished migrating iscsi to native systemd units and socket activating it and that has been submitted upstream and accepted ( not sure what's taking Chris Leech such a long time to apply those changes and build an updated package in rawhide ).
As you can see we still have a lot of things to do, to properly integrate systemd into the distribution thus I personally fail to see why at this point we need to result taking extreme actions against maintainers even thou the underlying problem is the same as from the get go as in getting maintainers to actually package and ship the submitted units and that problem is not limited to systemd but rather maintainer(s) themselves in general afaikt.
Some do it immediately, some do it after some time ( due to time,some upstream discussion/cleanup ) and others don't do it et all and as we have discussed before we cant really have proven packagers to blindly go and package those units without an green light from maintainers since some of the units might break something that we, that are migrating those units are unaware of.
FESCo on today's meeting agreed upon this:
Changing the sysv init scripts to systemd units is highly encouraged even to provenpackagers willing to help. We will revisit the situation 1 week before F19 branch point to see if we can just have provenpackagers to finish them, or set deadline.
Replying to [comment:9 tmraz]:
FESCo on today's meeting agreed upon this: Changing the sysv init scripts to systemd units is highly encouraged even to provenpackagers willing to help. We will revisit the situation 1 week before F19 branch point to see if we can just have provenpackagers to finish them, or set deadline.
Finish what exactly packaging them or converting them? because I already have process in for migrating this stuff and the last thing I need is for me or others suddenly be double working on the same components etc.
Atleast if the intent is for provenpackagers to start migrating units they should consult me first after all I'm the feature owner and the individual responsible to ensure this is done properly.
And for the love of all holy can we please drop the legacy sysv init scripts instead of having the distribution carry it for no purpose other then to cause users confusion and trouble etc.
Replying to [comment:10 johannbg]:
Reference sample to what I'm talking about.
Once a unit has been migrated the legacy sysv init script should be dropped from the distribution.
Some components are shipping both, some components are shipping the units with wrong file permission and some components are shipping this in a subpackage which serve absolutely no purpose.
1.http://lists.fedoraproject.org/pipermail/test/2012-December/112547.html
I think packaging... in any case, yes, folks should check existing bugs and coordinate, not do their own thing.
Sure, communication is always good.
We call these bugs. ;) Please file them and help maintainers fix things up...
http://lists.fedoraproject.org/pipermail/test/2012-December/112547.html
The init script they refer to is a local file, not anything packaged as far as I can see.
Replying to [comment:12 kevin]:
Replying to [comment:10 johannbg]: Finish what exactly packaging them or converting them? because I already have process in for migrating this stuff and the last thing I need is for me or others suddenly be double working on the same components etc. I think packaging... in any case, yes, folks should check existing bugs and coordinate, not do their own thing. Atleast if the intent is for provenpackagers to start migrating units they should consult me first after all I'm the feature owner and the individual responsible to ensure this is done properly. Sure, communication is always good. Some components are shipping both, some components are shipping the units with wrong file permission and some components are shipping this in a subpackage which serve absolutely no purpose. We call these bugs. ;) Please file them and help maintainers fix things up...
I have been doing that all this time just search for "Legacy sysv init script should be dropped or package separately as stated by the FPG" in bz.rh
http://lists.fedoraproject.org/pipermail/test/2012-December/112547.html The init script they refer to is a local file, not anything packaged as far as I can see.
We have subpackages for dozen or so packages which contain the legacy sysv init scripts which serve no other purpose then to cause trouble and make things more difficult for us.
Native systemd unit files always take precedence over legacy sysv init scripts so even for the remote weird reason/possibility individual chooses to install that sub-package to use the legacy sysv init script he will have to, at each package update remove the unit file that get installed by the package update.
Honestly I fail to see the reasoning for fesco/fpc allowing this in the first place so feel free to enlighten me what benefits doing this is supposed to brings us.
In anycase give this some serious thoughts and please considered in the F19 time frame to drop those packages and forbid legacy sysv init script to be shipped once they have been migrated to native systemd units.
I'll create a wikipage with the remaining packages that need to be migrate in F19 ( like 1 ) and try to migrate quite a few over the holidays.
1.http://fedoraproject.org/wiki/User:Johannbg/Features/SysVtoSystemd-F17
The legacy sysvinit subpackages were allowed at time when it was not yet 100% sure that we will not revert from systemd to upstart or other sysvinit startup. I agree that they should be dropped now.
sysvinit subpackages are not there for that reason. They are there because other init systems are packaged in Fedora and packagers may choose to support them. The subpackages were a means to do that which required the sysadmin of a system to be explicit about installing them.
The sysvinit subpackages were '''not''' intended to be of use on a standard Fedora system which used systemd as its init system.
Replying to [comment:15 toshio]:
Which other init system to we ship and maintain?
To me that logic only works if all or at least majority of the components would ship them not just a hand full of maintainers and their components...
The total number of packages which ship daemons and ship legacy sysv init are 32 afaict which makes up roughly 6% of the total and looking at which components those are I honestly dont see their purpose heck I dont think they can even make up the "base" needed for "other" init system thus I propose they will get dropped along with the support for shipping both in F19.
3proxy-sysvinit-0:0.6.1-14.fc18.x86_64
acpid-sysvinit-0:2.0.17-1.fc19.x86_64
at-sysvinit-0:3.1.13-10.fc19.x86_64
bird6-sysvinit-0:1.3.7-2.fc18.x86_64
bird-sysvinit-0:1.3.7-2.fc18.x86_64
clamav-server-sysvinit-0:0.97.6-1900.fc19.noarch
cronie-sysvinit-0:1.4.10-3.fc19.x86_64
cyrus-sasl-sysvinit-0:2.1.25-2.fc19.x86_64
device-mapper-multipath-sysvinit-0:0.4.9-42.fc19.x86_64
exim-clamav-sysvinit-0:4.80.1-1.fc19.noarch
exim-sysvinit-0:4.80.1-1.fc19.noarch
giis-sysvinit-0:4.6.2-3.fc19.x86_64
ip-sentinel-sysvinit-0:0.12-1900.fc19.noarch
iputils-sysvinit-0:20121221-1.fc19.x86_64
lvm2-sysvinit-0:2.02.98-4.fc19.x86_64
net-snmp-sysvinit-1:5.7.2-4.fc19.x86_64
opensm-sysv-0:3.3.15-3.fc19.x86_64
openssh-server-sysvinit-0:6.1p1-4.fc19.x86_64
openvas-manager-sysvinit-0:3.0.4-1.fc19.x86_64
openvas-scanner-sysvinit-0:3.3.1-2.fc19.x86_64
postfix-sysvinit-2:2.9.5-2.fc19.noarch
quagga-sysvinit-0:0.99.21-4.fc18.x86_64
rdma-sysv-0:2.0-6.fc19.noarch
rpld-sysvinit-0:1.8-0.15.beta1.fc18.x86_64
sendmail-sysvinit-0:8.14.6-1.fc19.noarch
squid-sysvinit-7:3.2.5-1.fc19.x86_64
srptools-sysv-0:0.0.4-16.fc19.x86_64
tomcat6-systemv-0:6.0.35-5.fc18.noarch
tomcat-systemv-0:7.0.34-1.fc19.noarch
util-vserver-sysv-0:0.30.215+svn2929-1603.fc18.x86_64
vsftpd-sysvinit-0:3.0.2-1.fc19.x86_64
wine-sysvinit-0:1.5.21-1.fc19.noarch
I don't see reason, why they shouldn't stay there. They are not installed by default. Maintainers created them according to guidelines. It's more a question for FPC if they want them or not. We might decide for a change of init system again and then they might be needed. On the other hand it might be found in older branches in git.
Replying to [comment:18 mmaslano]:
It would be good to get a clarification if FESCO is deciding to change init system in the near future then I can just stop doing the work I'm doing now.
Replying to [comment:19 johannbg]:
Replying to [comment:18 mmaslano]: I don't see reason, why they shouldn't stay there. They are not installed by default. Maintainers created them according to guidelines. It's more a question for FPC if they want them or not. We might decide for a change of init system again and then they might be needed. On the other hand it might be found in older branches in git. It would be good to get a clarification if FESCO is deciding to change init system in the near future then I can just stop doing the work I'm doing now.
I'm fairly sure that comment was made in a purely theoretical nature. FESCo has no plans to change the init system, nor are there any Features being submitted to suggest so.
I don't see reason, why they shouldn't stay there. 1. They are not useful to users, so users shouldn't see these packages. 1. With the several improvements/obsoletions in the unit files that we've seen already, it's likely that provenpackagers and other volunteers will be updating the unit files, not only the package owner. These people will not be too likely to look at the sysv init files, and even the package owner is presumably running systemd; so I'd expect the sysv init files to fall behind the unit files and slowly bit rot. What benefit is there in having a bitrotted file on the master branch?
If anyone wanted a sysv init file, they could always get it from the git history - with the implied warning that it might need updating.
Replying to [comment:20 jwboyer]:
Replying to [comment:19 johannbg]: Replying to [comment:18 mmaslano]: I don't see reason, why they shouldn't stay there. They are not installed by default. Maintainers created them according to guidelines. It's more a question for FPC if they want them or not. We might decide for a change of init system again and then they might be needed. On the other hand it might be found in older branches in git. It would be good to get a clarification if FESCO is deciding to change init system in the near future then I can just stop doing the work I'm doing now. I'm fairly sure that comment was made in a purely theoretical nature. FESCo has no plans to change the init system, nor are there any Features being submitted to suggest so.
Good to know you got me scared there for a moment.
Backing out of systemd at this point is no go both from a distribution standpoint as is for various upstream.
And whatever the future brings it most definitely wont be reverting to either the legacy sysv or upstart for that matter so I think that argument is moot.
Can someone explain to me which other init systems that are packaged in Fedora Toshio is referring to?
Replying to [comment:21 mitr]:
Replying to [comment:18 mmaslano]: I don't see reason, why they shouldn't stay there. 1. They are not useful to users, so users shouldn't see these packages. 1. With the several improvements/obsoletions in the unit files that we've seen already, it's likely that provenpackagers and other volunteers will be updating the unit files, not only the package owner. These people will not be too likely to look at the sysv init files, and even the package owner is presumably running systemd; so I'd expect the sysv init files to fall behind the unit files and slowly bit rot. What benefit is there in having a bitrotted file on the master branch? If anyone wanted a sysv init file, they could always get it from the git history - with the implied warning that it might need updating.
To me it makes absolutely no sense continuing shipping the legacy sysv initscripts once they have been migrated and I personally never understood why FPC did not just ask or simply put in the guidelines for those that wanted to continue ship legacy sysv they could simply do so by putting the script into docs for the the component. Administrators would then just rename the file and move it under /etc/rc.d/init.d and disable the unit and enable the script which is what they essentially need to do if they want to continue to use the legacy sysv initscript but that does not prevent it from bit rotten nor is it any guarantee that it will continue to work if the upstream component has been adapted to take advantage of the various bits systemd provided but at least having it there would not cause unnecessary confusion from users/admin thinking they can easially continue to use the scrip like they always have.
I personally don't see any point in the sysvinit files shipped in the packages in comment 17.
Probibly the best approach to dealing with them would be:
{{{ "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." }}}
Change that to say once a package has been converted sysvinit scripts should not be shipped (or can only be shipped as %doc, or whatever).
Once thats done, note to devel list the new guideline.
Wait a bit, file bugs on any that are not dropped
I've started to go through which packages we have left and made a list here [1] note that the current status on them is incomplete ( we have migrated many of them so those might be shipping both or none of those units ).
There seem to be few packages there that should be obsolete like bluez-compat,yum-*, sysklogd( is these still needed? ) for example so it would be good if fesco members could skim over this list to see if there is something that should be deprecated etc.
I'm also seeing new packages there so there might be crack in our review process which we need to fill in.
1.https://fedoraproject.org/wiki/User:Johannbg/Features/SysVtoSystemd-F19
I agree with kevin's proposal.
I agree as well.
I agree with Kevin. That's 4. Anyone else?
Clarified at today's meting that the proposal is for FPC to revisit the Guidelines and consider changing them rather than requesting that they change them.
I can vote +1 with that clarification.
+5 is quorum, correct? should I just open a ticket for fpc?
sure, please do.
https://fedorahosted.org/fpc/ticket/243
please add yourself to cc for that ticket if you are interested in the outcome.
In relation to [1], can fesco explain what benefits it is to the distribution to continue to package and ship sysvinit/upstart at this point since I think I can safely say that we have cross the bridge of no return and those packages should be dropped from the distribution to prevent giving users the fake notion that they can still use sysvinit or upstart as an alternative to systemd in the distribution both from usability and packaging perspective.
Do you mean drop packages, which are working fine? I read the FPC ticket and I didn't find any reason, why we should punish maintainers of working packages.
Sorry not following what do you mean by punish and how would we be doing that?
But I ask of you ( and other fesco members or perhaps fesco could ask the maintainers them self to do that ) try switching and using init system to sysvinit and upstart in the distribution and then make an informed decision if a) it actually is possible b) serves any benefit to the distribution continuing shipping them.
What was the reason not dropping sysvinit when we switched to upstart in F9 and does the argument for not doing that still apply today?
It boils down answering to these question.
a ) Can it be used?
( Shed's light on if these init solution can still be used or of we are shipping components that cant be used in the distribution thus warrant removal from a clear cleanup perspective )
b ) Who's using it? ( Show the actual userbase surrounding the component )
c ) For what purpose? ( Highlight any limitation we might be dealing with in systemd )
I guess the maintainers ought to be able to answer all these question and be sitting on a goldmime of a sysv/upstart LSB compliant init script you know for all the components that only ship native systemd units with the exception of those 26 components that ship both ( not that it matters at this point even thou you do have sysv/upstart LSB compliant init script for the baseos i'm pretty sure still would not be able to boot a functional system using sysvinit/upstart )...
Should this ticket be closed now?
The latest round of activity in this ticket seems to be around the packaging guidelines. The packaging guidelines were updated recently to ban sysvinit scripts in new packages if a systemd unit file is provided:
https://fedorahosted.org/fpc/ticket/359
and packagers are encouraged to drop sysvinit subpackages if they are carrying them.
The migration of service units is not completed so I would assume we need to leave it open until I have finished it
This ticket hasn't seen any activity for a year. Is there any remaining work to be done here?
The process isn't done, if that is what you're asking. I refreshed https://bugzilla.redhat.com/show_bug.cgi?id=713562, and a few of the bugs are still open.
I'd like to finish the conversion. There's a bunch of packages which are missing service files and are not on that list. I'll open bugs for them. SysV script support is nowadays rarely used, so it is probably getting slightly rusty, and it doesn't seem nice to require new administrators to learn the old stuff for the remaining handful of packages.
If FeSCo wants to formulate some statement about the conversion, that would be nice, but isn't necessary.
I'm not going to take this to the meeting this week, but I'd like to make a proposal for Fedora 23 here for FESCo to vote on.
Proposal: Any package in Fedora that provides a SYSV init script instead of a systemd service unit will be dropped from the distribution at the branch point of Fedora 23.
We're well into a systemd world and basically every other distribution has made the switch. I think it's probably about time that we finished this off. If FESCo agrees with this plan, we should make the announcement immediately so as to offer basically a full six months for projects to adapt.
If an insufficient number of votes are seen before the 2015-03-04 meeting to approve or reject this proposal, we should add it to the agenda.
I think it's a thing worth considering.
Some statistics (on F22): {{{ $ repoquery -f /etc/init.d/*|grep -E 'sysvinit|initscript'|sed 's/-[0123]:.*//' → 0
$ repoquery -f /etc/rc.d/init.d/*|grep -E 'sysvinit|initscript'|sed 's/-[0123]:.*//' → 17 pptpd-sysvinit 3proxy-sysvinit clamav-server-sysvinit opendkim-sysvinit ip-sentinel-sysvinit systemtap-initscript perdition-sysvinit exim-clamav-sysvinit net-snmp-sysvinit giis-sysvinit postfix-sysvinit initscripts acpid-sysvinit wine-sysvinit exim-sysvinit sendmail-sysvinit device-mapper-multipath-sysvinit
}}}
Those subpackages can be dropped immediately, since a systemd service file presumably exists in the main package. Actually this might be done for F22, since packages can be dropped until final freeze, and those are completely useless.
{{{ $ repoquery -f /etc/init.d/*|grep -Ev 'sysvinit|initscript'|sed 's/-[0123]:.*//'|sort -u → 11 conmux cyphesis dircproxy ldirectord powerman ratbox-services snake-server spawn-fcgi sslogger-slogd svxlink-server vhostmd
$ repoquery -f /etc/rc.d/init.d/*|grep -Ev 'sysvinit|initscript'|sed 's/-[0123]:.*//'|sort -u → 96 bdii ceph ceph-common ceph-radosgw cfengine clement compat-qpid-cpp-server-ha dahdi-tools dhcp_probe dpm-dsi drbdlinks fts-infosys fts-msg fts-server gearmand globus-gatekeeper globus-gridftp-server-progs globus-scheduler-event-generator-progs gmediaserver greylistd i8kutils ibmasm imagefactory initscripts # good question what to do with this one. # /etc/init.d/network is still used and some users want to hold onto it iodine-client iodine-server koji-builder koji-utils koji-vm mimedefang mogilefsd mogstored mom monotone-server moodle mysql-proxy ncid ncid-client ncid-samba ncid-speak nessus-server netdump-server nightview-server noip nordugrid-arc-acix-cache nordugrid-arc-acix-index nordugrid-arc-arex nordugrid-arc-aris nordugrid-arc-cache-service nordugrid-arc-datadelivery-service nordugrid-arc-egiis nordugrid-arc-gridftpd nordugrid-arc-hed nordugrid-arc-ldap-infosys nxtvepg oidentd openscada openslp-server opentracker-ipv4 opentracker-ipv6 orbited pathfinderd Perlbal pgbouncer pnp4nagios popfile psad RabbIT ris-linux root-proofd root-rootd roundup sagator-core ser sigul sks smstools ssbd sys_basher sysklogd systemd # not really ;) tabled tetrinetx thebridge tmda-ofmipd torque-mom torque-scheduler torque-server ttywatch ulogd vmpsd voms-server Vuurmuur-daemon xtide yum-updateonboot }}}
Some of those have had systemd units submitted. For example all three koji-* packages had units written during a sprint in Flock in Charleston. Many others probably too. OTOH, I'm not convinced that converting all of them to systemd units would actually provide much gain. For example noip: a conversion would basically mean that the sysvinit script is moved to /usr/libexec and a systemd service wrapper is provided for it. This does not differ from what happens now.
So I'd propose an amended proposal:
(before F22 final freeze) Drop sysvinit scripts if a systemd unit file exists (all -sysvinit, -initscript subpackages, and possibly cases where a sysvinit script and a systemd unit file are provided in the same package).
(F23 branch point) Drop packages from the distribution that provide a sysvinit script instead of a systemd unit, except when
a) the script does not start anything and does the work itself (e.g. noip, network)
b) the script cannot be easily converted to a systemd unit because it does some significant work on its own (I'm not aware of any examples atm).
I think it is a reasonable compromise, that would allow us to get rid of the majority of those scripts, but leave a way out to convert problematic scripts on a best-effort basis.
So my humble opinion to this as initscripts maintainer. I agree that we should at least consider dropping packages without unit-files. BUT I would not like to drop support for initscripts completely. There are 3rd party products which still only ship initscripts and we can't convince them to also provide unit-files. So for initscripts package I would remove it from default installation, but keep it in distribution.
Replying to [comment:44 lnykryn]:
Can all the backwards legacy sysv compatibility be moved to a single component to install encase 3rd party still ship/support ( or only ships ) legacy sysv initscript?
The bottom line is that as long as we continue to support it they wont be forced to do something about which means they never will migrate their legacy sysv init script and or modernize their component in the process until they absolutely have to and is quite frankly it is silly telling the packaging maintainers in the distribution that their package is going to be dropped due to the fact they contain a legacy sysv initscript while at the same time say hey 3rd party we still support yours legacy sysv initscript...
There are two ways compatibility can go: 1. support running of sysvinit scripts by systemd 2. providing sysvinit scripts for daemons packaged for Fedora
The first is here to stay. it would be a disservice to our users to drop that. Let's not discuss this here.
This ticket is about the second.
silly telling the packaging maintainers in the distribution that their package is going to be dropped due to the fact they contain a legacy sysv initscript while at the same time say hey 3rd party we still support yours legacy sysv initscript... We generally hold our packages to a higher standard than what can be installed by hand. I don't see a problem with doing that here.
Replying to [comment:46 zbyszek]:
There are two ways compatibility can go: 1. support running of sysvinit scripts by systemd 2. providing sysvinit scripts for daemons packaged for Fedora The first is here to stay. it would be a disservice to our users to drop that. Let's not discuss this here. This ticket is about the second. silly telling the packaging maintainers in the distribution that their package is going to be dropped due to the fact they contain a legacy sysv initscript while at the same time say hey 3rd party we still support yours legacy sysv initscript.. . We generally hold our packages to a higher standard than what can be installed by hand. I don't see a problem with doing that here.
silly telling the packaging maintainers in the distribution that their package is going to be dropped due to the fact they contain a legacy sysv initscript while at the same time say hey 3rd party we still support yours legacy sysv initscript.. . We generally hold our packages to a higher standard than what can be installed by hand. I don't see a problem with doing that here.
You probably mean packages maintenance are being held to double standard these days since Red Hat has effectively manage to re-introduce cores and extra in the form of products.
Bottom line is a ) we go to the lengths of actually migrating those remaining 150 components ( arguably we should leave that work up to those FESCo/FPC members that thought they where such experts on that matter after all those initscripts not being migrate is a result of them ) or b ) we allow legacy sysv initscripts to continue to be shipped until the day we stop supporting them altogether.
Ethic cleansing of components based on them containing legacy sysv init while still allowing it exist for 3rd partyś will lead to nothing else other than further reduction of participation of package maintainership in the distribution.
I don't really see it as being a double-standard at all. It's saying that "Services that Fedora ships in its repositories must work natively with the init system provided by Fedora". Packages that are not shipped by Fedora will always continue to do whatever they see fit, and attempting to block the SYSV compatibility layer would likely have no effect other than to drive those non-Fedora upstreams to use other distributions.
I very much doubt that it would have any meaningful impact on the inclusion of packages INTO Fedora, particularly because all of the major distributions are moving to systemd. It's SYSV init scripts that are the exception, not the rule today. That would not have been true two years ago, or even at the start of the F21 process, but with Debian and Ubuntu making the transition, it has changed the landscape and offered us this opportunity to finally go the last mile on this.
Replying to [comment:48 sgallagh]:
The double standard you recently introduce via differences of package maintainership between "products" ( core ) and the rest ( extra )
And you cannot hold back progress based on some hypothetical third party we have no knowledge about other than we know they exist out there and they may or may not already support Fedora.
You know as well as I do the best way for those 3rd party avoid being excluded in distributions is to participate and maintain components in them as well as the fact that the industry has no clue where they want to go these days ( containers not containers vm's etc ) so we can just as well support existing components shipping legacy sysv initscripts until we officially drop that 3rd party support and keep the maintainers and users of those existing components happy until that time comes.
That exception and opportunity you speak of is nothing but illusion the fact is Debian and thus Ubuntu ( even thou it could move at faster pace in systemd implementation than Debian ) are way far behind than any other distribution implementation and integration of systemd into their distribution ( compared to others, they stand basically where we stood around F14/F15 ) both in terms of distribution policy's and migration to native systemd units ( The end result for Debian is pretty clear if they intent to do that effectively they will have to settle on a single init system or their maintainers will have to provide and maintain two version of the components maintain, one compiled to use systemd and or provide units and one not compiled with systemd support or shipping legacy sysv initscripts ( or one of those other gazillion initsystem they support ).
On top of that last time I checked Debian had about 600+ components shipping legacy sysv initscript that we did in Fedora so them migrating it anytime soon is not happening ( which means upstream will neither that is if they actually do care about or ship initscripts et all ).
And I'm pretty sure your reluctance to drop the compatibility support for legacy sysv initscripts has more to do with RHEL interested than it does for an distribution with relative short release cycle which those 3rd you seem to be referring to already ignore due to that fact.
Replying to [comment:43 zbyszek]:
Yeah, that makes sense to me as a goal. (It’s even somewhat useful to keep a few init.d scripts around just to make sure that the compatibility mechanism still works; from a quick look systemd git seems to have a test but that test is not hooked into any test harness—and regardless of whether systemd upstream wants to test this, Fedora does want this to continue to work.)
Implementation-wise, * For all the actions we need to figure out ''who'' will do them, especially if the proposed goal involves making human judgment about the contents of dozens of packages. (And there is also the question of how will the human decision be tracked, but that's primarily up to the people doing the work.) * Just to be explicit, we should make sure that the existing bugs to port to systemd unit files are updated with a comment that says that the package will be removed if… (or file new bugs if there are no existing bugs). Removal of a package should never be a surprise to the maintainer, and historically we’ve not been this strict on packaging policies. (Though I think it is generally the right direction to go.)
Replying to [comment:50 mitr> * Just to be explicit, we should make sure that the existing bugs to port to systemd unit files are updated with a comment that says that the package will be removed if… (or file new bugs if there are no existing bugs). Removal of a package should never be a surprise to the maintainer, and historically we’ve not been this strict on packaging policies. (Though I think it is generally the right direction to go.)
If FESCo/FPC members aren't going to accept responsibility for their own action and do all that work themselves then they should step out of the way of the people that were doing that work willing. grant them proven packager ability to implement this in the remaining components for the duration of the migration period and forever hold their peace.
Submitting yet again for yet another release cycle unit to bug reports will get this and other systemd integration effort nowhere so you can just as well drop those component immediately if that is the intent.
to give a data point, yes someone sent in a patch to port koji to systemd but it was not something we could accept upstream. we still support running koji on rhel 5 and that is likely to stay for quite some time still. feed back was given that systemd units had to co-exist with initscripts but no further updates have been received
Replying to [comment:52 ausil]:
Replying to [comment:43 zbyszek]: Some of those have had systemd units submitted. For example all three koji-* packages had units written during a sprint in Flock in Charleston. Many others probably too. OTOH, I'm not convinced that converting all of them to systemd units would actually provide much gain. For example noip: a conversion would basically mean that the sysvinit script is moved to /usr/libexec and a systemd service wrapper is provided for it. This does not differ from what happens now. to give a data point, yes someone sent in a patch to port koji to systemd but it was not something we could accept upstream. we still support running koji on rhel 5 and that is likely to stay for quite some time still. feed back was given that systemd units had to co-exist with initscripts but no further updates have been received
So are you saying that those building the koji rpm's could not handle adding an ifdefs to their specs where <rhel 5/6 added the initscript and else did not?
Based on that response and the most recent proposal on how this should be handle koji should be dropped from the distro...
Replying to [comment:53 johannbg]:
I have to agree with Jóhann than expecting that systemd maintainers (or other people working on systemd integration in Fedora) provide full integration for every package is completely unrealistic. I'd think that if somebody contributes unit files, the maintainer can tweak the spec file to use them.
to give a data point, yes someone sent in a patch to port koji to systemd but it was not something we could accept upstream. feed back was given that systemd units had to co-exist with initscripts but no further updates have been received
Actually, I provided a version which did just that. Quoting https://bugzilla.redhat.com/show_bug.cgi?id=995753#c20 (2014-04-21 15:36:58 EDT):
(In reply to Zbigniew Jędrzejewski-Szmek from comment #20)
(In reply to Dennis Gilmore from comment #15) Still the patches are not acceptable, they remove sysvinit support that we have to maintain still. The new versions leaves sysvinit in place for F<21 and RHEL<7.
(In reply to Dennis Gilmore from comment #15)
Still the patches are not acceptable, they remove sysvinit support that we have to maintain still.
The new versions leaves sysvinit in place for F<21 and RHEL<7.
Replying to [comment:54 zbyszek]:
Replying to [comment:53 johannbg]: So are you saying that those building the koji rpm's could not handle adding an ifdefs to their specs where <rhel 5/6 added the initscript and else did not? I have to agree with Jóhann than expecting that systemd maintainers (or other people working on systemd integration in Fedora) provide full integration for every package is completely unrealistic. I'd think that if somebody contributes unit files, the maintainer can tweak the spec file to use them.
One would have expected that being the case but in reality I had to update those spec files as well so Toshio,Tom or Jon could use their proven packaging privileges and apply those submitted patches with least effort and time.
You can thank that stupid decision making which forced two or more individuals to do the work mostly to Marcela Mašláňová sucking up to Steve Dickson ( Yup the guy that frowned upon systemd and or Lennart and left NFS broken for several release and was recently spotted upstream trying to pull his pants up and properly fix that breakage 5 years after we introduced it in Fedora, which I believe Tom G. ended up cleaning up after him ) and majority of those FESCo members at that time.
On and on those FESCo members should have done all that work themselves along with other non systemd related fixes maintainers had asked me to conduct once I had received those packaging privileges ( which Toshio or Stephen decided to ask for without as much as asking or consulting that decision with me first ) since they did not have time for it instead of needlessly signing up proven packagers to do that work for them.
Replying to [comment:55 johannbg]: Jóhann, please let it go. Instead of talking who did what and when and why, let's concentrate on technical matters.
Replying to [comment:56 zbyszek]:
The individuals that make up FESCo/FPC need to learn to take responsibility for their own action and they most certainly wont learn from past mistakes if they manage to get away with their previous behaviour as has been the case for the past 10 years.
That said this is not technically complicated and even if it was FESCo/FPC are not the ones signing themselves up to deal with the relevant technical complexity in roughly 300+ man hours it takes to finish this.
Option a)
FESCo/FPC gets out of the way of people actually doing any work in the distribution and grants us proven packaging ability and gets out of our way and we finish the migration or finish what we can migrate before X time frame ( F23 as Stephen proposed or something else ) or when we need to start focusing on preparing the distro for "factory reset"
Option b)
Do as Stephen proposed and drop those components that have not be migrated.
Take your pick...
Resolved in today's fesco meeting to prune sysvinit scripts (and subpackages) for packages where there is a systemd unit file available, in F23.
Shouldn't the pruning of sysvinit sub-packages have been accompanied by an "Obsoletes: %{name}-sysvinit < %{version}-%{release}" or equivalent in the main packages so as not to create broken dependency issues for people upgrading to F-23 that have any of the sysvinit sub-packages installed?
Adam catching me by surprise here already doing the removal work credit for that
Anyway out of those what 17 components these are the package potentially breaking people setups ( with the exception of potential dependency issues Paul points out ) ip-sentinel-sysvinit, clamav-server-sysvinit, perdition-sysvinit, wine-sysvinit once removed
The rest should just continue to use the shipped unit as it has always done and should be safe to remove in F22 for that matter...
List of components
3proxy-sysvinit ( never worked initscript named same as unit )
acpid-sysviniti ( never worked initscript named same as unit )
clamav-server-sysvinit ( worked initscript does not bare the same name as the unit )
device-mapper-multipath-sysvinit ( never worked initscript named same as unit )
exim-clamav-sysvinit ( never worked initscript named same as unit )
exim-sysvinit ( never worked initscript named same as unit )
giis-sysvinit ( never worked initscript named same as unit )
net-snmp-sysvinit ( never worked initscript named same as unit )
opendkim-sysvinit ( never worked initscript named same as unit )
openvas-manager-sysvinit ( never worked initscript named same as unit subpackage already removed F22+ )
openvas-scanner-sysvinit ( never worked initscript named same as unit subpackage already removed F22+ )
perdition-sysvinit ( worked initscript does not bare the same name as the unit )
postfix-sysvinit ( never worked initscript named same as unit )
pptpd-sysvinit ( never worked initscript named same as unit )
sendmail-sysvinit ( never worked initscript named same as unit )
wine-sysvinit ( worked not sure what's going on with that wine.conf in the wine-systemd package thou )
I've dropped just about all of the sysvinit subpackages from F23 at this point. There's another dozen or so packages with both sysvinit and systemd scripts, which I'll get to over the next week.
Beyond that I intend to focus first on those packages with the most "consumers", as those are in some sense the ones people are most likely to need to install. For a metric, I'm arbitrarily using number of packages printed for "repoquery --whatrequires --recursive" for a package. At the moment that list looks like:
{{{ cfengine: 1 ibmasm: 1 orbited: 1 dahdi-tools: 2 ip-sentinel: 2 mysql-proxy: 2 pnp4nagios: 2 tmda: 2 ttywatch: 2 nessus-core: 3 ser: 3 root: 4 sysklogd: 4 Vuurmuur: 4 ulogd: 5 ceph: 7 globus-gridftp-server: 7 Perlbal: 7 monotone: 8 systemtap: 9 bdii: 10 mom: 10 globus-gatekeeper: 26 imagefactory: 27 globus-scheduler-event-generator: 35 nordugrid-arc: 43 openscada: 45 koji: 52 voms: 162 yum-utils: 216 torque: 855 }}}
And then another ~40 of pure leaf packages:
{{{ clement: 0 compat-qpid-cpp: 0 dhcp_probe: 0 dpm-dsi: 0 drbdlinks: 0 fts: 0 gearmand: 0 gmediaserver: 0 greylistd: 0 i8kutils: 0 iodine: 0 mimedefang: 0 moodle: 0 ncid: 0 netdump-server: 0 nightview: 0 noip: 0 nxtvepg: 0 oidentd: 0 opendmarc: 0 opentracker: 0 pathfinder: 0 perl-mogilefs-server: 0 pgbouncer: 0 popfile: 0 psad: 0 RabbIT: 0 ris-linux: 0 roundup: 0 sagator: 0 sigul: 0 sks: 0 smstools: 0 ssbd: 0 sys_basher: 0 tabled: 0 tetrinetx: 0 thebridge: 0 vmpsd: 0 xtide: 0 }}}
ip-sentinel is a weird one. It contains init scripts for sysvinit, upstart (!), and something called minit that appears to be of approximately 2005 vintage, but nothing for systemd. I suspect this is some form of political statement and/or performance art piece.
Interesting if I'm understanding the last response correctly, Adam you seem to be planning diving head first into the migration process and continue to surprising me in the process. Credit for that.
Some word of advice here.
Since you are an upstream developer and a package maintainer I need to ask you, you are perfectly aware of how much of your freetime this will take and as result of that how much it will distract you from coding and fixing bugs upstream/downstream in the process right?
You will need to get familiar with each components setup and it's environment since you will need to properly test this while migrating this.
Once the unit has been prepared and works in said components environment/setup and you start working on the spec file itself you need to test the upgrade path before submitting it ( in my case since I was prevented from doing that myself, thanks to your predecessors, in your case applying those patches directly since you can ).
Bear in mind the cron to timer migration when going through those components since those should be migrated in the process, as well as any other work the baseWG is doing and might be relevant to the component you are going through.
On in on expect 3 hours minimum of work per component ( anything less than that you have started to cutting corners, most likely skip testing it )
First and foremost before you start doing any of that work ensure that there are actual maintainers behind those components otherwise you are just wasting that time on a deadweight in the distribution.
The cleanup process in the distribution is utterly and complete broken or non existing ( again thanks to your predecessors hence #967 )
I dont know how many hours I burned working on components that had no maintainers,unresponsive maintainers or simply maintainers that forgotten they intended to drop this components so take your time ensure one way or another that those components are being used and maintained before you start working on them.
That said I will be observing how you are migrating components and good luck.
Comparing status of F22 and F23:
{{{ $ repoquery -f /etc/rc.d/init.d/*|grep -E 'sysvinit|initscript'|sed 's/-[0123]:.*//' -pptpd-sysvinit -3proxy-sysvinit -clamav-server-sysvinit -opendkim-sysvinit -ip-sentinel-sysvinit -systemtap-initscript -perdition-sysvinit -exim-clamav-sysvinit -net-snmp-sysvinit -giis-sysvinit -postfix-sysvinit initscripts -acpid-sysvinit -wine-sysvinit -exim-sysvinit -sendmail-sysvinit -device-mapper-multipath-sysvinit +systemtap-initscript → rhbug#1245873 +ip-sentinel-sysvinit → rhbug#1245876 }}}
Kudos for ajax on this.
{{{ $ repoquery -f /etc/rc.d/init.d/*|grep -Ev 'sysvinit|initscript'|sed 's/-[0123]:.*//'|sort -u bdii ceph ceph-common ceph-radosgw cfengine clement compat-qpid-cpp-server-ha dahdi-tools dhcp_probe dpm-dsi drbdlinks fts-infosys fts-msg fts-server -gearmand globus-gatekeeper globus-gridftp-server-progs globus-scheduler-event-generator-progs gmediaserver greylistd i8kutils ibmasm imagefactory -initscripts iodine-client iodine-server -koji-builder -koji-utils -koji-vm mimedefang mogilefsd mogstored -mom monotone-server moodle mysql-proxy +nagios ncid ncid-client ncid-samba ncid-speak nessus-server -netdump-server nightview-server noip nordugrid-arc-acix-cache nordugrid-arc-acix-index nordugrid-arc-arex nordugrid-arc-aris nordugrid-arc-cache-service nordugrid-arc-datadelivery-service nordugrid-arc-egiis nordugrid-arc-gridftpd nordugrid-arc-hed nordugrid-arc-ldap-infosys nxtvepg oidentd openscada -openslp-server opentracker-ipv4 opentracker-ipv6 orbited -pathfinderd Perlbal pgbouncer pnp4nagios popfile psad RabbIT ris-linux root-proofd root-rootd roundup sagator-core ser sigul sks smstools ssbd sys_basher sysklogd systemd tabled tetrinetx thebridge tmda-ofmipd -torque-mom -torque-scheduler -torque-server ttywatch ulogd vmpsd voms-server Vuurmuur-daemon xtide yum-updateonboot }}}
So there's progress. At this rate the process should be done somewhere by F33.
On track with what I had suspected.
The period for migration stops at every beta freeze ( 2015-09-08 ) so there is time for him to migrate some more.
Any update here like how much work has been done and when should this ticket be considered as resolved?
Comment 64 shows the progress on this ticket. There are some small improvements between the state in comment 64 and current rawhide, but not too much.
Replying to [comment:66 pnemade]:
This ticket is resolved either when all the legacy sys v initscripts have been migrated or the components shipping those will be dropped from the distribution.
The options remain the same as I mentioned in comment 57.
If FESCo/FPC has not learned it's lesson Ajax should be more experienced in the migration process now so he should be faster migrating components in the F24 development cycle thus more progress should be made ( that is should he decide to take another joyful round at this ) or FESCo can vote on what Stephen proposed in comment 42.
So first of all, I'd like to say "thank you" to Ajax. We're considerably further-along than we were eight months ago. That being said, I think Johann is right and this is the correct time to consider enacting an "ultimatum" approach. So, I'm going to put this back on the meeting agenda for next week with the following proposal:
Any package in Fedora that provides a SYSV init script '''instead of''' a systemd service unit will be retired from the distribution at the branch point of Fedora 25 (which usually equates to Alpha Freeze). Exceptions will be considered on a case-by-case basis if submitted through a FESCo ticket at least three weeks prior to the branch point. FESCo will coordinate with the Change Wrangler to provide periodic reminders of this deadline mailed out. FESCo explicitly does '''not''' advocate the removal of the sysvinit compatibility functionality from systemd itself, as we do not want to negatively impact third-party software that may still be relying upon it.
This proposal explicitly does not address the -sysvinit subpackage cases (meaning that they are not subject to having the srpm retired from Fedora as long as they provide a systemd unit that is fully functional).
I would not say considerably but further along yes and why wait to F25?
It's better to drop those components now ( F24 ) and have everything thoroughly tested before RHEL 8 gets out the door since RH did not bother to do the necessary cleanup on existing units and make them "enterprise" ready before shipping them in RHEL 7 ( all that work still remains to be done. The actual "migration" was just phaze one for Fedora which I will assume will also fall under FESCo that work unless they learned their lesson and intend to step out of the way people actually doing all this work. ).
With regards to 3rd party that backwards compatibility support should be dropped altogether since you can not have 3rd party act as hindrance in the future direction and evolvement of the project ( it's enough that Red Hat does that ) and or it packaged separately and not shipped in the core/baseOS by default as in that third party would have to install "compatibility" package.
Replying to [comment:70 johannbg]:
The approved F24 schedule has the branch date as February 2nd. That seems a bit short, but if the rest of FESCo is cool with that, I'm amenable to moving it up.
It's better to drop those components now ( F24 ) and have everything thoroughly tested before RHEL 8 gets out the door since RH did not bother to do the necessary cleanup on existing units and make them "enterprise" ready before shipping them in RHEL 7 ( all that work still remains to be done.
I'm not really sure where this idea came from. Everything shipped in RHEL itself was migrated and I'm pretty sure that's not actually relevant from the Fedora perspective except so far as Red Hat expended the resources to get it done for those packages in both places.
The actual "migration" was just phaze one for Fedora which I will assume will also fall under FESCo that work unless they learned their lesson and intend to step out of the way people actually doing all this work. ).
I'm attempting to translate this. I ''think'' you're asking for provenpackagers to be told "go forth and convert"? If so, I'm fine with that but I think that's a second proposal to consider once the current one is approved (if it is).
I don't really understand this piece. I may be wrong, but isn't sysv-init compatibility just a core piece of systemd. I'm not sure how one would subpackage it out. Even if it could be, I don't think there's any real value in annoying third-party developers and forcing them to take extra steps to run on Fedora. Anyway, the inclusion or removal of that feature is specifically not part of the proposal I made. If you want to raise it as another request that can be voted on separately, I have no problems with that, but I suspect you will need a convincing argument to remove a backwards-compatibility feature.
Anyone knows how the implementation should be done? Is this correct
1)If package contains sysvinit and systemd service unit file then keep the packaging as it is.
2)If package contains only sysvinit file then try to migrate it to new systemd unit file. a) If its not possible then consider that as candidate package for retirement in F25 schedule.
b) If possible to migrate then add that as a new source file and install it. Then remove existing sysvinit file from installing in the same package update?
Replying to [comment:72 pnemade]:
Anyone knows how the implementation should be done? Is this correct 1)If package contains sysvinit and systemd service unit file then keep the packaging as it is.
That makes no sense and was some fesco/fpc proposed/approved idiocy since in practice this never has and never will work.
If you have hard time to understand why that is then I suggest you do what FESCo/FPC did not when proposing/appproving/setting those guidelines and actually implement the both in the same component and or a single component with either the type unit file in a sub package or type sysv initscript in sub package or both then perform updates/upgrades etc.
You can also crawl through the Debian bug tracker to see issues associated with supporting this since Debian is dead set on supporting every initsystem known since the beginning of the software universe.
Once a legacy sysv initscript has been migrated to native systemd type unit files that legacy sys v initscript should be dropped altogether from the distribution or you need to carry sub package for every init system you are intended to support which depends on the component.
Johann, please, cut down on the negativity.
Once a legacy sysv initscript has been migrated to native systemd type unit files that legacy sys v initscript should be dropped altogether from the distribution
Yes. Relevant part of the guidelines: https://fedoraproject.org/wiki/Packaging:SysVInitScript#Initscripts_in_addition_to_systemd_unit_files.
"Packagers MUST NOT include SysV initscripts in addition to systemd unit files, even in a separate $name-sysvinit subpackage"
Yes, but this should only be done in rawhide and should be prominently featured in the changelog because there is automatic migration of enablement status.
Replying to [comment:74 zbyszek]:
My negative only stems from the people that make up the FESCo/FPC and their actions and (bad) decisions which they themselves need to start taking responsibility for.
Heck we would not be having this discussion if they had granted me the prove packagers privileges in the request that Toshio made without me even knowing about it since I would have been finishing migrating all this stuff already and would be midst in the cleanup process.
But here we are and there is a lesson in there for them to learn.
Once a legacy sysv initscript has been migrated to native systemd type unit files that legacy sys v initscript should be dropped altogether from the distribution Yes. Relevant part of the guidelines: https://fedoraproject.org/wiki/Packaging:SysVInitScript#Initscripts_in_addition_to_systemd_unit_files. "Packagers MUST NOT include SysV initscripts in addition to systemd unit files, even in a separate $name-sysvinit subpackage"
Which contradicts the statement here [1]
"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."
Replying to [comment:72 pnemade]: b) If possible to migrate then add that as a new source file and install it. Then remove existing sysvinit file from installing in the same package update? Yes, but this should only be done in rawhide and should be prominently featured in the changelog because there is automatic migration of enablement status.
Thanks I just wanted to understand how can I help here with implementation.
Replying to [comment:75 johannbg]:
Which contradicts the statement here [1] "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." https://fedoraproject.org/wiki/Packaging:Systemd
Hmm, I suspect that's legacy and just plain incorrect. I'm happy to submit an edit to remove that and bring it in line with https://fedoraproject.org/wiki/Packaging:SysVInitScript#Initscripts_in_addition_to_systemd_unit_files, unless anyone on FESCo wants to object.
Replying to [comment:76 pnemade]:
Replying to [comment:74 zbyszek]: Replying to [comment:72 pnemade]: b) If possible to migrate then add that as a new source file and install it. Then remove existing sysvinit file from installing in the same package update? Yes, but this should only be done in rawhide and should be prominently featured in the changelog because there is automatic migration of enablement status.
Typo: the is no automatic migration.
By providing (or committing, if already provided) systemd unit files for packages from the list in comment 64. Some of those should probably be dropped anyway, e.g. yum-updateonboot.
Replying to [comment:77 sgallagh]:
That would be great. I guess that all documentation for sysvinit scripts should be removed then, i.e. https://fedoraproject.org/wiki/Packaging:SysVInitScript should be either totally removed or changed to have a prominent notice that it is provided only for the sake of external software packaged for Fedora.
Replying to [comment:78 zbyszek]:
That would be great. I guess that all documentation for sysvinit scripts should be removed then, i.e. https://fedoraproject.org/wiki/Packaging:SysVInitScript should be either totally removed
This makes sense and should be implemented at the same release cycle the component that have not been migrated will be dropped.
Perhaps it's just time for FESCo to decide from which Fedora release they intent to only support systemd with native systemd integration ( no backwards compatibility shipped by default in the core/baseOS ).
Announce that then unofficially support legacy sysv initscript" for whatever-time-frame-they-think-is-necessary before removing the backward compatibility ( package ) entirely from the distribution.
intent to only support systemd with native systemd integration
FTR, I'm -1 to dropping sysvinit support in systemd in Fedora.
Replying to [comment:80 zbyszek]:
intent to only support systemd with native systemd integration FTR, I'm -1 to dropping sysvinit support in systemd in Fedora.
Could you explain why please?
I see no reason to remove sysvinit support downstream in Fedora's systemd package. There's still likely old packages that people may want to use with init scripts. I would say we should continue to support those until systemd upstream drops sysvinit support.
Replying to [comment:82 kevin]:
Exactly.
Replying to [comment:83 zbyszek]:
Replying to [comment:82 kevin]: I see no reason to remove sysvinit support downstream in Fedora's systemd package. There's still likely old packages that people may want to use with init scripts. I would say we should continue to support those until systemd upstream drops sysvinit support. Exactly.
Thank you to the both of you. That makes sense.
FWIW, I read too quickly on zbyszek's earlier reply and missed the "...in systemd.." part.
Replying to [comment:69 sgallagh]:
Any package in Fedora that provides a SYSV init script '''instead of''' a systemd service unit will be retired from the distribution at the branch point of Fedora 25 (which usually equates to Alpha Freeze). Exceptions will be considered on a case-by-case basis if submitted through a FESCo ticket at least three weeks prior to the branch point. FESCo will coordinate with the Change Wrangler to provide periodic reminders of this deadline mailed out. FESCo explicitly does '''not''' advocate the removal of the sysvinit compatibility functionality from systemd itself, as we do not want to negatively impact third-party software that may still be relying upon it. This proposal explicitly does not address the -sysvinit subpackage cases (meaning that they are not subject to having the srpm retired from Fedora as long as they provide a systemd unit that is fully functional).
I may not be able to attend today's FESCo meeting. I'm +1 in your proposal. Also with possible change including removal of "-sysvinit subpackage cases" and modifying the documentation on wiki accordingly. I also agree with sgallagh's proposal in comment:77 and zbyszek's addition in comment:78.
Any package in Fedora that provides a SYSV init script instead of a systemd service unit will be retired from the distribution at the branch point of Fedora 24. Exceptions will be considered on a case-by-case basis if submitted through a FESCo ticket at least three weeks prior to the branch point. FESCo will coordinate with the Change Wrangler to provide periodic reminders of this deadline mailed out. FESCo explicitly does not advocate the removal of the sysvinit compatibility functionality from systemd itself, as we do not want to negatively impact third-party software that may still be relying upon it. We will also update all packaging documentation around the use of SYSV init scripts to indicate that its use in Fedora is not recommended, but that it may be useful for EPEL.
I probably close this ticket as we have got above decision. Please re-open when anyone want any more discussion here.
We really need to ''announce'' this decision. I propose the following message for devel-announce list:
At the FESCo meeting on August 14th, it was [https://lists.fedoraproject.org/pipermail/devel/2015-October/215791.html decided] that the time has come to finally complete the migration away from System V init scripts. What does this mean for you as a packager?
When we branch from Rawhide for Fedora 24 (currently [https://fedoraproject.org/wiki/Releases/24/Schedule scheduled] for February 2nd, 2016), we will be immediately retiring any package in the Fedora collection that relies on a System V init script instead of a systemd unit file to start. We will consider reasonable requests to delay this action on a case-by-case basis for anyone who [https://fedorahosted.org/fesco/newticket submits a ticket] to FESCo no later than 23:59 UTC on January 12, 2016.
There is no plan to remove System V compatibility from Fedora, due to the necessity of supporting legacy third-party software. We are also not at this time making any changes at all to the EPEL project. EPEL packages may continue to use System V init scripts (in the case of EPEL 5 and EPEL 6, there is no other option).
We will be going through the Wiki packaging documentation over the next month and updating all related entries to reflect this change in policy.
This will be the first such announcement. The Change Wrangler will be sending additional reminders from now until February 2nd, so no one will be surprised by this event.
Minor nit: I'd drop the "...at this time..." part from the EPEL section. People get all worked up about phrases like that because they imply we might change it in the future. We have intention to do that, so there's no reason to leave a foot in the door.
Other than that, I'm fine with it.
Replying to [comment:89 jwboyer]:
Minor nit: I'd drop the "...at this time..." part from the EPEL section. People get all worked up about phrases like that because they imply we might change it in the future. We have intention to do that, so there's no reason to leave a foot in the door. Other than that, I'm fine with it.
Well, I was leaving that open in case we (or EPSCo) decided to change the policy for EPEL 7 (or a future EPEL 8). But I can just drop "at this time", sure.
I'll plan to send this out on Monday, which should be enough time for other feedback.
sgallagh has now sent the decision to devel-announce, so this can be closed.
I've also opened a [https://fedorahosted.org/fpc/ticket/577 ticket] with FPC to update the Packaging Guidelines. They did have one clarifying question: are new packages that provide only sysvinit now explicitly forbidden? I responded with "yes", since I can't think of any reason why we'd allow that immediately before dropping unconverted packages, but if anyone feels strongly that we should treat this differently, please speak up.
I would expect new packages to atleast be able to ask for an exception.
OK, I guess we'll have to bring that to a vote.
I'm opposed to allowing any new package into the distribution that relies on SysV instead of systemd. We might grant exceptions for certain critical legacy software, but anything new should simply be required to fall in line.
Replying to [comment:95 sgallagh]:
OK, I guess we'll have to bring that to a vote. I'm opposed to allowing any new package into the distribution that relies on SysV instead of systemd. We might grant exceptions for certain critical legacy software, but anything new should simply be required to fall in line.
I agree here. It seems silly to retire existing packages with this problem only to allow new ones in. So no, new packages cannot rely on SysV init compatibility and will need to convert to a systemd unit file.
We haven't sent the reminder emails like we intended to. I've asked jkurik to send one today. Fortunately, the schedule has slipped out by three weeks, so if we remind people now, they'll still have time before the branch deadline.
Replying to [comment:97 sgallagh]:
We haven't sent the reminder emails like we intended to. I've asked jkurik to send one today. Fortunately, the schedule has slipped out by three weeks, so if we remind people now, they'll still have time before the branch deadline. [[br]] Reminder sent to [https://lists.fedoraproject.org/archives/list/devel-announce%40lists.fedoraproject.org/thread/ULPGRGI3OBFXWZISXRIX2S3Z35RBCMBN/ devel-announce@] and [https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject.org/thread/ULPGRGI3OBFXWZISXRIX2S3Z35RBCMBN/ devel@] lists.
Login to comment on this ticket.