install_initd clobbers system init symlinks

I've just observed on SuSE that install_initd can move
the boot order of some symlinks, even if install_initd was
called to manage different services.  

Example: I have an init script called foo.  I explicitly
create the following symlinks:

/etc/rc.d/rc3.d/S90foo  -> /etc/init.d/foo
/etc/rc.d/rc4.d/S90foo  -> /etc/init.d/foo
/etc/rc.d/rc5.d/S90foo  -> /etc/init.d/foo

Then, I run install_initd for a different service.  Example:
  /usr/lib/lsb/install_initd bar

Now I have the following symlinks:

/etc/rc.d/rc3.d/S09foo  -> ../foo
/etc/rc.d/rc4.d/S09foo  -> ../foo
/etc/rc.d/rc5.d/S09foo  -> ../foo

Note that "90" was changed to "09", even though 
I used install_initd on service foo, not bar.  

This happens whether or not the foo script
contains the INIT INFO data documented here:
http://www.linuxbase.org/spec/refspecs/LSB_1.3.0/gLSB/gLSB/initscrcomconv.html

Is this a SuSE bug, or the desired behavior for 
install_initd?  

I think this is very bad.  If a sysadmin, through trial
and error, finds the right boot order, and explicitly creates
symlinks, they should not 
be changed the next time an RPM postinstall script
runs /usr/lib/lsb/install_initd.

-- 
Bart Whiteley <[email protected]>
Novell, Inc., the leading provider of information solutions
http://www.novell.com/