[Pm-utils] Re: Resume via quirks, not using the DBUS method, Was: Release Candidates ?

[Michael Biebl]

2007/3/6, Peter Jones <pjones at redhat.com>:
> On Tue, 2007-03-06 at 16:31 +0000, Richard Hughes wrote:
> > On 06/03/07, Peter Jones <pjones at redhat.com> wrote:
> > > On Tue, 2007-02-20 at 21:30 +0100, Stefan Seyfried wrote:
> > >
> > > > Before getting towards 1.0, shouldn't we move over from /etc/ to
> > > > /usr/lib/pm-utils or something like that to be FHS compliant? Somebody
> > > > mentioned recently to me that having these scripts in /etc/pm/hooks seemed
> > > > a bit strange to him. I am not very good at that FHS stuff, but IIUC only
> > > > configuration stuff should live in /etc?
> > >
> > > Yes, I think I agree with you.
> > >
> > > So I'm thinking we actually want something like:
> > >
> > > /etc/pm/config             # the default config file
> > > /etc/pm/config.d/          # empty by default
> > > /etc/pm/sleep.d/           # empty by default
> > > /etc/pm/power.d/           # empty by default
> >
> > Adding that this is where the ISV's and distros should push random stuff.
>
> I find myself wondering if /etc/pm/config shouldn't really
> be /usr/lib/pm-utils/config , actually.  That would make /etc/pm
> entirely the domain of the admin (and any ISV software he adds)

Imo putting config files in /usr/lib/ is a bad idea. No one expects
them in /usr/lib, Debian policies forbid it and I also think the FHS
does not promote this.


>
> > > /usr/lib/pm-utils/bin/
> > > /usr/lib/pm-utils/bin/pm-action
> > > /usr/lib/pm-utils/bin/pm-pmu

I'd use ${libexec} for that. On some platforms this resolves to
/usr/libexec/$file, on other (like) debian to /usr/lib/pm-utils.
It is mean for executables/scripts which should not be run directly
(exactly what we do).

> > > /usr/lib/pm-utils/functions
> > > /usr/sbin/pm-suspend       # symlink to pm-action above
> > > /usr/sbin/pm-hibernate     # symlink to pm-action above
> >


Cheers,
Michael