Right now, /etc/init.d is CONFIG_PROTECTed by default. This is bad because: * Unmerges (especially when switching between equivalent tools such as cron daemons or sysloggers) leave all sorts of mess behing by default, causing lots of confusion. * When upgrading, init script updates are generally mandatory. * User changes to init scripts should be done via conf.d. This is good because: * Some init scripts aren't very good at being customised, so the user may have to modify the init script directly. Personally I'm in favour of CONFIG_PROTECT_MASKing /etc/init.d by default as it makes most packages 'do the right thing'. If anyone really feels the need to tinker with init scripts they can always override the mask... Thoughts?
*** Bug 50387 has been marked as a duplicate of this bug. ***
The reason I was given a long time ago was that users like to change /etc/init.d files. There are many many things I don't think should be masked, but changing things that people are familiar with just makes them irate.
I have several scripts in init.d that would get clobbered if overwritten. I think it's one of those places where the user should have control lest a reboot render a system inaccessible.
Staying as it is.
*** Bug 85271 has been marked as a duplicate of this bug. ***
*** Bug 112637 has been marked as a duplicate of this bug. ***
