some comments on the 0.9 spec
(cc: me, please; I'm not on the list ATM.)
Mainly in regards to the init script section.
> Package Dependencies
>
> Packages must depend on a dependency "lsb". They may not depend on other
> system-provided dependencies. If a package includes "Provides" it must
> only provide a virtual package name which is registered to that
> application.
This seems *very* broken to me.
What this implies:
- if a package requires any 'reasonably standard' component of a distribution,
but one that isn't specifically stated in the LSB, that means that the
package must include/statically link all these components.
- in fact, now that I think about it, if you can't require the particular
libc you were compiled against, does that mean that all LSB packages must
be linked statically?
> Cron Jobs
> ...
> The scripts in these directories have to check, if all necessary programs
> are installed before they try to execute them. Otherwise, problems will
> arise when a package was removed (but not purged), since the configuration
> files are kept on the system in this situation.
> ...
> Init Script Actions
> ...
> These executable files should not fail obscurely when the configuration
> files remain but the package has been removed, as the default in [the
> packaging system] is to leave configuration files on the system after the
> package has been removed. Only when it is executed with the [purge] option
> will [the packaging system] remove configuration files.
This 'purge' behavior is not specified anywhere under package management.
Unless it's part of the spec, there's no reason to mention anything about
it here.
> All error messages should be printed on standard error. All status
> messages should be printed on standard output.
I think this is overly restrictive; there are definite situations where
you'd want these error messages redirected somewhere else (for example,
to logs.)
> Comment conventions for init scripts
> ...
> In the init.d file, information about the shell script is delimited by the
> strings "### BEGIN INIT INFO" and "### END INIT INFO".
IMO, that's *ugly*.
> Inside this block
> declarations shall take the form of "# {keyword}: [arg1] [arg2] ..." The
> following keywords, with their arguments are defined in this specification:
>
> # Provides: boot_facility_1 [ boot_facility_2 ...]
> # Required-Start: boot_facility_1 [ boot_facility_2 ...]
> # Required-Stop: boot_facility_1 [ boot_facility_2 ...]
> # Default-Start: run_level_1 [ run_level_2 ...]
> # Default-Stop: run_level_1 [ run_level_2 ...]
> # Description: multiline_description
Putting the description here is a bad idea; it's a pain to update and
maintain, and it makes translating it (for possible configuration tool
use) a bear. I don't know where else this sort of information would be
stored, but just because there isn't anyplace currently better to put
it doesn't mean it should go here.
> An init.d shell script may declare using the "Required-Start: " header that
> it must not be run until certain boot facilities are provided. This
> information is used by the installation tool or the boot-time boot-script
> execution facility to assure that init scripts are run in the correct order.
>
> Similarly, the "Required-Stop:" header defines which facilities must still
> be available during the shutdown of that service. Hence, the initscript
> system should avoid stopping shell scripts which provide those facilities
> until this shell script is stopped.
This is what the normal SysVinit numbering scheme is for. We can always
ignore it, but:
a) some things are going to expect it to be supported
b) it will make the 'rc' script heinously ugly (in fact, it will
most likely cause it to not be a script anymore)
If you try to implement this on top of the current SysVinit
ordering semantics, you run the risks of your orderings conflicting
with each other.
> Facility names
> ...
> $named is operational
This nees clarified. Obviously, in the great majority of cases, this is
*never* true. Are you actually asking for when external name resolution
is available?
> Script names
> ...
> * Assigned namespace. This namespace consists of names which only use
> the character set [a-z0-9].
Case sensitve or not? Obviously, naming a script K[0-9][0-9]foo would
be bad.
> Init script Functions
> ...
> Each LSB complaint
Typo, I *think*. :)
> start_daemon [-f] [-n nicelevel] pathname [args]
> This runs the specified program as a daemon. start_daemon will check
> to see if there is a program named "daemon" already running. If so,
> it will not start another copy of the daemon unless the -f option is
> given. The -n option specifies a nice level. See nice(1).
This probably needs to clarify what 'starting the progam as a daemon'
entails; is it up to the start_daemon function to close file descriptors
and background the process, or do we assume that the daemons are written
sanely?
Bill
Reply to: