I think this is a perfectly acceptable exception. It makes things easier/more clear for our users and helps them migrate to the new way to do things. So, I am +1 personally.

We should consider asking FPC if anyone there can think of a reason to not allow this.

Yeah, this should be an FPC consideration, not a FESCo decision. Or perhaps it needs to be approved by both as it conflicts with both the packaging guidelines and with http://fedoraproject.org/wiki/Features/SysVtoSystemd

At the moment, the standard answer would be to just use the script in /usr/bin/ (if it has been added to the package yet.) The init system, according to systemd is not intended to do that (whether or not it can be made to is another matter, of course).

If you have a link to the thread in the fedora-devel list I'll open the FPC ticket for you. I won't promise to champion it though (I'm actually very tired of dealing with systemd stuff so I pretty much will only read and vote on proposals, not write new guidelines around it). So someone else, perhaps you or perhaps a diffeent FPC member, will need to make the effort of researching problems, answering questions, writing guidelines, testing, etc.

To be a little clearer about what I wrote:

I think the FPC would want to decide whether having init scripts that did work that wasn't handled by systemd were allowable. If they are, then they'd want to write the recipe for how those should look (like the init script in the bugzilla, I imagine). They'd want testing to show how systemd behaves with this, what happens when people try things like chkconfig --levels 345 on initscript, how this interacts with people who try to uses a different init system and need to have SysV style init scripts that work there. Be warned that testing is the hardest part as there is quite a large matrix of possible starting conditions to choose from.

FESCo would want to decide if they want to amend the portions of the Feature that talk about what happens to the sysv init script when upgrading to systemd scripts and perhaps make explicit that the old upgrade may leave these sysv scripts installed for this specific purpose.

FWIW, I don't think an iptables-specific exception makes sense. The postgresql, network and quite a few other initscripts have additional actions that are almost as commonly documented and used.

OTOH, figuring out a general way that allows us to allow any of these commands to work again is attractive to me.

BTW, does making firewalld default make this issue less important?

I agree with mitr. The FPC guidelines should be provided more broadly for all units, which are missing some sysvinit functionality. Even better, shouldn't systemd provide such functions? I guess one of systemd features was making units files easier.

Replying to [comment:5 mitr]:

figuring out a general way that allows us to allow any of these commands to work again is attractive to me.

The goal should not be to make the commands work again. The idea is to make the old commands print a helpful message to guide the user to the new commands. The old commands should not be shipped perpetually, but for a few releases at most. The new commands should be in /usr/bin and ideally they should come from upstream, in order to strengthen unification across distributions.

Michal Schmidt, systemd comaintainer

Replying to [comment:8 michich]:

Replying to [comment:5 mitr]:

figuring out a general way that allows us to allow any of these commands to work again is attractive to me.

The goal should not be to make the commands work again. The idea is to make the old commands print a helpful message to guide the user to the new commands.

Well, my goal is different; I can't see any good reason not to to keep old commands working. Given that /sbin/service was always a RHL/Fedora interface, not a cross-distribution standard, that existing documentation was always distribution-specific and breaking that documentation won't make it distribution-agnostic, especially when the proposed alternative is also Fedora-specific (... and violating the FHS, btw :( )

The old commands should not be shipped perpetually, but for a few releases at most. The new commands should be in /usr/bin and ideally they should come from upstream, in order to strengthen unification across distributions.
If upstream wanted to ship something in /usr/bin, that would be fine, but it doesn't currently, so that is not helpful for answering the question of what environment and migration path does Fedora want to provide to its users.

Replying to [comment:9 mitr]:

Well, my goal is different; I can't see any good reason not to to keep old commands working.

So be it. But at the very least, they should first print a message pointing the user to the newly preferred upstream command, provided such a command exists.

Given that /sbin/service was always a RHL/Fedora interface, not a cross-distribution standard, that existing documentation was always distribution-specific and breaking that documentation won't make it distribution-agnostic,

Of course. It's pushing the useful commands upstream that will make them distribution-agnostic. /sbin/service should at best remain as a compatibility wrapper, not as the primary interface.

We should also consider moving the scripts implementing the compatibility actions for /sbin/service away from /etc/rc.d/init.d somewhere else because they won't really be SysV scripts anymore. /sbin/service will have to be patched.

especially when the proposed alternative is also Fedora-specific (... and violating the FHS, btw :( )

Are you referring to /usr/libexec/iptables.init specifically? I agree with you that it is not the right location and I have said so in the BZ.

If upstream wanted to ship something in /usr/bin, that would be fine, but it doesn't currently, so that is not helpful for answering the question of what environment and migration path does Fedora want to provide to its users.

We should always encourage Fedora developers to work with upstream and add missing functionality there, instead of working around it by having Fedora sauce added to packages.

Replying to [comment:10 michich]:

We should also consider moving the scripts implementing the compatibility actions for /sbin/service away from /etc/rc.d/init.d somewhere else because they won't really be SysV scripts anymore. /sbin/service will have to be patched.

This move should actually make the breakage that [comment:4 Toshio] was concerned about a lot less likely.
And since the compatibility scripts wouldn't be SysV scripts, no exception should be needed to do exactly that.

I filed a RFE for initscripts: https://bugzilla.redhat.com/show_bug.cgi?id=796663

notting as the initscripts long time maintainer should decide, what will be the appropriate solution. I'm not comfortable with loosing feature of iptables, but FESCo should propose something suited to more applications. Do we know about any others broken initscripts?

Replying to [comment:13 mmaslano]:

I'm not comfortable with loosing feature of iptables,

Strictly speaking, the features are not lost, they are just accessed using different commands.

but FESCo should propose something suited to more applications.

I agree. The solution should be suitable for any package that provided non-standard initscript actions in previous Fedora releases.

Do we know about any others broken initscripts?

I know postgresql used to use "service postgresql initdb" and "service postgresql upgrade". They simply documented new commands in F16 release notes:
http://docs.fedoraproject.org/en-US/Fedora/16/html/Release_Notes/sect-Release_Notes-Changes_for_Sysadmin.html#id2838704

In the 2012-02-27 meeting we agreed to:
ask FPC if we can add to systemd guidelines to allow for non standard service commands to continue to work in a systemd world.

https://fedorahosted.org/fpc/ticket/149

I'll note that FPC discussed this ticket in their last meeting:

"Packages which have SysV initscripts that contain 'non-standard service commands' (commands besides start, stop, reload, restart, or try-restart) must convert those commands into standalone helper scripts. Systemd does not support non-standard unit commands."

I've added support to initscripts for packagers to package such actions. See devel@ for details.