#243 consider a ban on sysvinit scripts
Closed: Invalid None Opened 11 years ago by toshio.

vikingice asked fesco to consider prohibiting shipping sysvinit scripts if the package already has a systemd unit file[1]. since it's a packaging question they passed it on to is to consider. our current guidelines allow sysvinit scripts to be shipped in a separate subpackage in this case. the rrationale is not to stand in the way of packagers who are packaging for other init systems than the default while establishing a boundary so that only sysadmins who purposely installed it would have them on their systems.

I didn't see any reason that the sysvinit aggravated were harmful in the fesco ticket, just a misunderstanding of what they were for. on the other side, after looking through the pkgdb, the only non-systemd init that we currently ship is sysv (the others that I found were orphaned).

i'm still somewhat of the opinion that if they don't cause harm them we should allow them. but I could see restricting init scripts/configuration to %doc unless we ship the init system as a fedora package. we'd need to find out if the sysvinit package qualifies as an init system or if it's so badly butchered that it no longer qualifies if this change were to be applied in a way that would satisfy the original request.

[1] https://fedorahosted.org/fesco/ticket/615#comment:13


FPC has considered a ban and feels that the optional sysvinit subpackage guideline that exists is sufficient. (+1:5, 0:0, -1:0)

Can you please add to all of the tickets you close reference in the discussion surrounding them.

I would very much want to see the reasoning you all are voting +1 for keeping them in the distribution.

http://meetbot.fedoraproject.org/teams/fpc/fpc.2013-02-06-17.02.log.html#l-128

This was a close vote. I think we basically could find no harm in having the separate subpackages and so it seemed to follow more with allowing maintainers discretion in those cases.

For the first it makes no sense to ship and maintain more then one init system in the distribution ( we can leave that madness to debian ).

Why are we even still shipping both sysvinit and upstart and are those packages being actively maintained upstream and with us?

Sysvinit has not had an upstream release in 2 years[1] and last commit was 5 months ago [2] and I'm not seeing patches for those fixes for it in the package in the distribution.

Upstart is at 1.8 release [3] yet we are only shipping 1.2 [4].

Sysvinit should have been dropped in Fedora 9 when we replaced it with upstart and upstart should have properly integrated in the distribution when we made that switch as it should be dropped now that we are fully committed to actively maintain and use systemd as our init systemd and for once properly intergrade it into the distribution ( which is what I and others from the systemd team are trying to do with all our work ).

The proposal of mine was only about dropping/ban shipping of the legacy sysv init script once it had been migrated to native systemd unit if not approved have the init script shipped as a doc file instead so we can properly keep tap on what's left to migrate.

So I ask FPC to do a little homework first make a simple repo query on a package that contains legacy sysv init script and see if you easily can identify if that/those packages are shipping unit files as well then actually try replacing a unit file with legacy sysv init script ( and update that relevant component ) to see how "easy" and "well" we support continues use of legacy sysv initscript once it has been migrated.

A larger ( easter ) weekend project for fpc to do is to replace systemd with either sysvinit and or upstart to see if the claim that we support and maintain more then one init system in the distribution holds any water. ( I would not be surprised if the first component that would prevent users from simply booting was dracut/udev at this point )

When you have done that re-vote on what was proposed and keep in mind that now is our opportunity to not repeat past mistakes replacing init system in the distribution.

Continuing to ship legacy sysv init script once they have been migrated only makes the life's of us that are trying to properly intergrade systemd into the distribution more miserable and give users the fake notion that we support more then one init system when in reality we only support systemd at this point.

  1. http://download.savannah.gnu.org/releases/sysvinit/

  2. http://svn.savannah.nongnu.org/viewvc/sysvinit/trunk/doc/Changelog?root=sysvinit&sortby=log&view=log

  3. http://upstart.ubuntu.com/download.html

  4. http://koji.fedoraproject.org/koji/packageinfo?packageID=5768

your comment adds nothing to the actual reason that the fpc declined this request.

( leaving ticket in closed state)

Login to comment on this ticket.

Metadata