[email protected] changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|LATER |
------- Additional Comments From [email protected] 2005-03-02 21:29 -------
Here's the problem as described in the linked message. It was written by
someone trying to write an application to use the lsb initscripts.
With respect to start_daemon, I don't see any clarity in the spec about what
"pathname' means (absolute pathname? pathname relative to something?).
The install_initd one would appear to be a case in which the spec is clear but
some implementations are lacking. Do we have a process for addressing that (I
think it was discussed at some point, but I don't know if any such thing ever
happened)? Of course, one process (perhaps the best) would be to write a test
case which covers these two.
Set -e looks like something that the spec needs to clarify (set -e is in POSIX).
(The question is whether an application can call the implementation provided
functions after having called set -e).
The only one I'm not readily able to parse is the chkconfig one. If there is
really a need for an LSB application to call chkconfig, it would seem to be a
deficient implementation (the installinit.sgml page explicitly says we don't
have chkconfig or anything which provides the same functionality).
* Seems start_daemon on mandrake 9.1 wants just the name, not the path,
so changed that. Note that my reading of the lsb says the path should
be there, and the debian implementation agrees. For now, supporting
mandrake is more important.
* Similarly, {remove,install}_initd on Mandrake seems not to want the full
path of /etc/init.d/mooix. This is clearly a violation of
the lsb, but for now I will cater to it.
* Remove set -e from lsb/init, since on Mandrake the init functions are not
-e safe. (Sheesh.)
* Add chkconfig stuff to lsb/init, since mandrake's sad excuse for a lsb
compliant init system seems to require it.
--
Configure bugmail: http://bugs.linuxbase.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.