Michael Meskes wrote: > On Fri, Aug 14, 2009 at 12:29:01PM -0500, Raphael Geissert wrote: >> Just out of curiosity, why would the sys admin change it in first place? if > > How about a local change that makes one process need ldap or a database to get > some data from while the default config doesn't do that? Or a software > monitoring some other software? > >> the order needs to be modified then it might warrant a bug report, don't you >> think? > > No, why? > >> Regarding preserving the modified order it seems impossible to me with the >> current design of update-rc.d, but I'll leave that up to the maintainer. > > I don't understand this sorry. It did work before the insserv mess was > introduced. Don't get me wrong, I actually like the dependency based approach > quite a lot, it just has to work, which it unfortunately didn't for me. > > You might also want to see the policy that under 9.3.3.1 says: > > The system administrator will have the opportunity to customize runlevels by > simply adding, moving, or removing the symbolic links in /etc/rcn.d if > symbolic > links are being used [...] > > I guess this alone warrants the RC status of this bug report.
Policy does not dictate what happens, but describes current practice AFAICT. So with changing practice, it's quite normal that policy still tells something different AFAICS. Note that a sysadmin can still decide to change the order by making sure that the header of the init script is correct for their environment. I'm not sure if they would need to rerun some insserv command in that case, but having the link changed and the header appropriate should work. Only changing the link will of course not always work, though that's what dependency based boot scripts are about. I guess a debconf message explaining that the dependencies have to be changed to change the boot order would be in order. Cheers Luk -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
