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...
*** 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. ***