Re: LSB Status
In article <[🔎] 20020107135335.A7311@svpal.svpal.org>,
Grant Bowman <grantbow@svpal.org> wrote:
>* Miquel van Smoorenburg <miquels@cistron.nl> [020107 12:39]:
>> Grant Bowman <grantbow@svpal.org> wrote:
>> >* Miquel van Smoorenburg <miquels@cistron.nl> [020106 22:23]:
>> >> Yes, but the spec is talking about *.lsb packages, NOT about
>> >> *.deb or *.rpm packages. Those don't have to be changed.
>> >
>> >Really? I guess that could be. On what basis do you make this
>> >distinction?
>>
>> Because the LSB standard is about LSB and not about Debian or Redhat.
>> You could implement LSB on windows (with cygwin) if you wanted.
>
>Mike, I read it a bit differently. Are you implying that Chapter 11
>"System Initialization" does not apply to Debian?
Indeed it doesn't apply to *Debian packages*.
> I think that Chapter
>specifies an API for system level functioning and is mandatory for LSB
>compliance.
No, it doesn't. That isn't specified anywhere in any way. Think about
it - just where does it say what exactly /etc/init.d/nis does, and
how LSB applications should call it? It doesn't.
In fact why would an LSB package ever want to start/stop/restart
parts of the system using /etc/init.d/<whatever> ? It shouldn't !
>This Chapter includes sections on cron jobs run-levels init
>scripts and script functions.
Right, but only for LSB packages.
What is very confusing is paragraph "Init Script Actions" where
as an example is said
"If a service reloads its configuration automatically (as in the case of
cron, for example), the reload option of the init file must behave as if
the configuration has been reloaded successfully."
This doesn't mean that an LSB package should ever call /etc/init.d/cron!
It's just an example of a package that *were it an LSB package*
should ignore the 'reload' option. Bad, confusing example.
Mike.
Reply to: