Little change on /lib/lsb/init-functions

[Karl Hegbloom]

On Sun, 2005-06-12 at 23:13 +0200, Alberto González wrote:
> Those packages could modify init-functions when installed, making it
> point to whatever file they need, as long as it conforms to the
> "interface" of the original file.

Are you saying that it should use 'dpkg-divert'?  I don't like that
approach very well.  It would be better to implement some sort of
overlay or PATH-shadowing system.  Overlay would work best, so that the
base functionality of the LSB init-functions could still be accessed
without needing to duplicate it.

Q: Does POSIX Bourne Shell support renaming functions to other symbols?
That is, can I rename a function that's defined in LSB init-functions to
some other name, overload the function, yet still call the LSB version
of it if I like, by it's new name?

If not, then, and perhaps simpler, the init-functions script could be
broken down into two or more parts, and the functions that are in it now
could be renamed with a lsb- prefix, then the init-functions script
could be a wrapper that pulls them in and wraps them with the API names.

That way, some arbitrary package would have the option to drop in a
script that shadows or overlays the lsb-init-functions one.  To
implement shadowing, the PATH can be used:

 #!/bin/sh
 # /etc/init.d/rc
 #
 # Set up PATH somehow...  it would have a dynamic configuration based
 # on the contents of a catalog file or directory, I suppose.
 PATH=$( get the path somehow )
 export PATH
 # ... do what I do.


 # -*- shell-script -*-
 # /lib/usplash/init-functions
 #
 PATH=${PATH#/lib/usplash:}
 . init-functions  # call next, then override them below.
 # ...


 #!/bin/sh
 # /etc/init.d/foo-daemon
 #
 PATH=$( setup path again in case run from command line )
 . init-functions    # from PATH


Maybe it could use 'shoop'?  :-)

-- 
Karl Hegbloom <hegbloom at pdx.edu>