Bug 60688 – Should /etc/init.d be CONFIG_PROTECT_MASKed by default?

• Product: Portage Development
• Status: RESOLVED WONTFIX

[Description Ciaran McCreesh 2004-08-17 09:43:54 UTC]

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?

[Comment 1 SpanKY 2004-08-26 22:02:09 UTC]

*** Bug 50387 has been marked as a duplicate of this bug. ***

[Comment 2 Nicholas Jones (RETIRED) 2004-09-08 22:52:47 UTC]

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.

[Comment 3 Brad Laue (RETIRED) 2004-09-08 23:52:57 UTC]

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.

[Comment 4 Nicholas Jones (RETIRED) 2004-09-21 18:24:49 UTC]

Staying as it is.

[Comment 5 SpanKY 2005-03-14 17:02:10 UTC]

*** Bug 85271 has been marked as a duplicate of this bug. ***

[Comment 6 SpanKY 2005-11-15 13:14:34 UTC]

*** Bug 112637 has been marked as a duplicate of this bug. ***