On 2016-01-21 16:18, Simon Hobson wrote:
> Rainer Weikusat <rainerweikusat@???> wrote:
>
>> I was specifically writing about using comment-syntax of programming
>> language A to embedd programming language B code into an 'A'
>> file. That's what I called 'a travesty' because of the double issue of
>> overloading comments with formal meaning and because the information
>> is
>> of no use to someone looking at the installed script.
>>
>> #! is an entirely different animal because the information is needed
>> for
>> running the script, it's also useful to someone looking at the script
>> code as it documents which interpreter is supposed to execute it and
>> it's really a 16-byte number supposed to conform to a convention how
>> older UNIX(*) kernels detected that a file was indeed an executable
>> and
>> the type of it. It presumably doubles up as 'shell comment' to be
>> somewhat portable to systems without this feature where the shell just
>> tries to execute anything the kernel cannot.
>>
>> But the 'LSB headers' were designed from scratch.
>
> Well yes, I do agree with you. If we didn't start from here, it
> wouldn't be a good system to adopt.
>
> But, from the starting point of "here", where init scripts are
> (msotly) shell scripts, and there's a large installed base, and you
> need a system that will co-exist with systems that aren't using the
> "new system"

This is an important reason. And another consideration was that it had
to be possible to continue to use the "old" (no LSB headers) and "new"
(LSB headers)" scripts all mixed together as "old style" numbered
scripts in runlevels, because you can't migrate to the new system
overnight without a *lot* of breakage. It took three stable releases to
complete this migration:

- disabled by default, could be optionally enabled (but wouldn't work
with all scripts due to missing headers and broken dependencies)
- enabled by default, could be optionally disabled (would work with most
scripts, with rare exceptions, and some broken dependencies)
- enabled by default, legacy static numbering dropped entirely

I think what Rainer might not fully be appreciating is the sheer scale
of the task, and that the compatibility constraints make this the least
disruptive and safest strategy. Moving an entire distribution from one
system to another is not a small undertaking. Most people wouldn't have
even noticed the migration going on, but in the background there was a
lot of testing and shaking out all the dependency issues--the numbered
script ordering was packed with implicit ordering assumptions which
needed to be turned into explicit dependencies. Could a cleaner method
have been devised? Yes. But that requires starting from a clean slate,
and that simply wasn't an option: we had to be able to smoothly and
transparently migrate using what we already had.

Other systems like openrc runscripts are much cleaner. But can you
easily intermix them with regular initscripts with or without LSB
headers? Not really, at least not without a lot of work to be able to
map LSB dependencies onto runscripts, and hook them into each other.
That would require having a runscript wrapper for LSB init scripts. If
Debian had chosen to switch to openrc, we'd have gone this route. And
when you consider which is cleaner, note that runscripts evaluate their
dependencies on the fly by recursion. It works fine, but note that the
LSB approach means you can scan and construct a global dependency graph
and map out the entire system in one pass. An openrc runscript only
"sees" the system in terms of its direct dependencies; there's no
higher-level view.


Regards,
Roger