On Fri, Apr 12, 2013 at 5:38 PM, Cristian Rodríguez
Why would it be meaningless?
It would tell you it refused to start|stop. That's all.
Yeah, but users expect sysvinit behaviour.. where there was no such thing as refusing to start or stop BECAUSE the init script said so, distinct from an error, misconfiguration..
Well, yes, expecting strict adherence to sysvinit behavior is ridiculous. One thing is retaining functionality, and another is getting pedantic about how that functionality behaves, when the underlying system behaves different. My point for rc scripts were, and I think others' too, about broad functionality, not the specific interface provided by sysvinit, but the general interface and ability to act on services beyond systemd's builtin actions, and within systemd's builtin actions, when those make sense. If a user script fails because it cannot start a service that is now forbidden from starting manually, or to perform an action that indeed cannot be performed now, then that's an underlying failure of the scripts' assumptions that has to be adapted to the new system, and one wants that to fail. It's not a simple "this command has been renamed so I have to change 100 scripts".
In any case, in those cases the package is configured as you say it's meaningless. We're all assuming discretionary judgement by the packager.
Problem is rpmlint does not have discretionary judgement.
Ok, true, but packagers can add an rpmlintrc, so packagers do have discretionary judgement. The transition can be handled with warnings, increasing badness, whatever works. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org