Hello - I draw your attention to a implementation which is intended to be compliant with the Provides: and Required-Start: keywords of: http://www.linuxbase.org/spec/gLSB/gLSB/initscrcomconv.html available at: http://www.fastboot.org
Also, some questions and observations. 1. Required-Stop: keyword My sense is that developers find it difficult enough to enumerate the start dependencies. Encouraging script developers to enumerate the stop dependencies seems like a big ask. Any pointers to the rationale behind this would be interesting. Is it under consideration to support an idiom whereby stop dependencies are simply the reverse of the start dependencies? In terms of the serel implementation, it would be of great assistance if someone could point me to an implementation of the Required-Stop: keyword. 2. Has consideration been given to a "last" keyword? A script with this keyword would run after all others have finished. Often times, this appears to be the semantics people desire when they use the SysV-style S99local script. 3. Deployed systems will invariably comprise some scripts containing these keywords and some scripts that don't. If boot scripts are run to in parallel, the interaction of these two classes of scripts is important, and it may be that putting parameters around this interaction would aid interoperability. 4. Scripts developers who wish to assert: "I don't know". After writing dependencies for over 50 popular services it appears to me that there is a signficant minority of script developers who wish to express: "I provide X, but I don't know what other services I depend on" These developers currently install as S99X. Rather than bundling these services into the "no dependency information" category, some mechanism to express this idiom may be useful. 5. Should-start and should-stop It appears that these new keywords are on the horizon: http://www.linuxbase.org/spec/gLSB/gLSB/initscrcomconv.html#AEN18935 There is a variety of semantics possible for such keywords, if there are any postings that hint at the intended direction, I would appreciate someone pointing them out to me. Cheers - Leni. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with subject of "unsubscribe". Trouble? Email [EMAIL PROTECTED]
