Bug 310539 - some SuSE management application removes gpm from runlevel 5 w/o my implisit consent
Summary: some SuSE management application removes gpm from runlevel 5 w/o my implisit ...
Status: VERIFIED FIXED
Alias: None
Product: openSUSE 10.2
Classification: openSUSE
Component: Basesystem (show other bugs)
Version: Final
Hardware: i686 openSUSE 10.2
: P3 - Medium : Normal (vote)
Target Milestone: ---
Assignee: Ales Nosek
QA Contact: Jiri Srain
URL:
Whiteboard:
Keywords: Bad_Design
Depends on:
Blocks:
 
Reported: 2007-09-14 10:06 UTC by Olli Artemjev
Modified: 2009-01-11 22:11 UTC (History)
2 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Olli Artemjev 2007-09-14 10:06:10 UTC
I'm tired to do do:

----------------- [ 13:46:53, root@sunbook, ~  ]
# chkconfig -l gpm
gpm                       0:off  1:off  2:on   3:on   4:off  5:off  6:off
----------------- [ 13:47:00, root@sunbook, ~  ]
# chkconfig gpm 2,3,5
----------------- [ 13:47:29, root@sunbook, ~  ]
# chkconfig -l gpm
gpm                       0:off  1:off  2:on   3:on   4:off  5:on   6:off
----------------- [ 13:47:31, root@sunbook, ~  ]
#

Some application I've not yet recognised touches the gpm presense in runlevels w/o my implicit consent. :/

Yes, I can use chattr +i on symlink, but it's definitely some brain damage in managing application - I periodically run, for example switching beetween network manager & traditional interface configuration due to another SuSE bug I've submitted on network manager. Also some times I install software & do other work w/ yast2. Any advises what kind of logging could be enabled to trace the problem to exact script/app?
Comment 1 Ales Nosek 2008-08-11 08:22:28 UTC

*** This bug has been marked as a duplicate of bug 340646 ***
Comment 2 Jan Engelhardt 2008-08-11 11:35:16 UTC
Unfortunate thing is that upgrading a package replaces /etc/init.d/PROGRAM, which means it gets new "Default-Start" and "Default-Stop" tags, and running insserv then updates the links in /etc/init.d/rc?.d according to these tags, effectively trashing your own, personal preferential, runlevel settings.

This affects any service. Any idea how to reasonably give way for unoverridable personal settings?
Comment 3 Ales Nosek 2008-08-11 12:12:57 UTC
Jan, this is a very interesting topic to discuss. Please, could you bring it to opensuse-packaging mailinglist?
Thank you
Comment 4 Jan Engelhardt 2008-08-24 00:39:05 UTC
Sent on August 11. Except that it was not replied to and probably forgotten already again.
Comment 5 Jan Engelhardt 2009-01-11 22:11:09 UTC
Done in 11.1.