[Pm-utils] Move pm/functions and hooks to /usr/lib or /usr/share

Stefan Seyfried seife at suse.de
Mon Mar 12 00:49:33 PDT 2007


On Sat, Mar 10, 2007 at 08:41:39PM +0100, Tim Dijkstra wrote:
> On Fri, 9 Mar 2007 16:53:48 +0100
> Stefan Seyfried <seife at suse.de> wrote:
> > no, more like:
> > 
> > /etc/pm/{hooks,sleep.d}/ having links
> > 01foo -> /usr/lib/pm/hooks/foo
> > 05bar -> /usr/lib/pm/hooks/bar
> > 99baz -> /usr/lib/pm/hooks/baz
> > 
> > So you add a link -> enable the hook
> > rm the link -> disable the hook
> > 
> > It is even more intuitive than the "set the x bit to enable, remove it to
> > disable" IMO.
> > The cream topping will be if somebody writes a "chkconfig" style hook-enable-
> > and-reorder-tool :-)
> 
> That is something I want to avoid. It will going to give me packaging
> nightmares. From a debian perspective it is much easier to have a
> scheme such as Peter proposed: Packages install in 
> /usr/lib/pm/{sleep,config,power}.d this are the scripts everybody 
> needs. They will be overridden on every upgrade. The user (administrator) 
> can put his local stuff in /etc/pm, the packages won't touch that.
> At execution time the contents of both directories will get merged 
> and sorted. If there is a possibility somebody doesn't want a certain
> script to be started it will have to get a config option.

Honestly, i'd like to avoid config options _for that_ since those also tend
to be painful in the upgrade case.

How about: only the distributed stuff gets the links in /etc/pm/hooks, the
admin still puts his own hooks directly in there? (This is what i did not
explicitly spell out in my proposal).

-- 
Stefan Seyfried

"Any ideas, John?"
"Well, surrounding them's out." 


More information about the Pm-utils mailing list