Michal Schmidt (mschmidt(a)redhat.com) said:
On 06/14/2012 11:00 PM, Bill Nottingham wrote:
>Michal Schmidt (mschmidt(a)redhat.com) said:
>>Packages wishing to provide legacy actions should install programs (probably
>>scripts, but could be binaries) named
>> /usr/lib/initscripts/legacy-actions/<service>/<action>
>>
[...]
>Hm. I'd rather just have /usr/lib/initscripts/legacy-actions/<service>,
and
>pass *whatever* to them.
Why? I think splitting the actions into separate files is superior.
It allows us to see from outside which actions are implemented.
Another advantage of the split is that maintainers do not get the
temptation to just copy their whole old SysV initscript as
/usr/lib/initscripts/legacy-actions/<service>.
That's exactly what I would encourage for simplicity's sake - why do you
think this is a bad idea? Simply because it would encourage accidental
overriding of start/stop/restart, etc.?
>The problem with that is how you structure the checking, because
if the
>init.d script doesn't exist, it will fall back to systemctl, which won't do
>this.
Not sure I understand what exactly you refer to by "this" here.
I first check if /etc/init.d/<service> exists. If yes, it wins.
Then I look for
/usr/lib/initscripts/legacy-actions/<service>/<action> and run it if
found.
The fallback to systemctl is run only if neither of the above was found.
I mean the problem with providing a single script for legacy actions is the
above - you need to do some hacks to pass those to a single script while
still falling back to systemctl for generic actions.
>Although, this implementation does mean that someone could
package
>/usr/lib/initscripts/legacy-actions/<service>/start, and then you've got a
>bit of a mess.
That should be solvable with a smack on the packager's head.
Absolutely.
Bill