On Tue, Nov 30, 2010 at 02:25:50PM -0500, Paul Wouters wrote:
> * after a reboot, the application is able to startup and write
to a directory
> in /var/run and/or /var/lock.
All daemons should already be able to do that (meaning init scripts dealing
with non-existing directories)
> corner cases:
> * After installation but before reboot, the application is able to startup
> and write to a directory in /var/run and/or /var/lock
Handled with the sam initscript code that should already exist.
Why? If the initscripts do this already it should be fine. The only
reason
I've heard so far is to do selinux context items, which I'm mostly
unfamiliar with (but would hope that most of the required permissions on
those are inherited from the parent directory policy?)
I would really like to avoid having THREE places to create directories
in /var/run and /var/lock, those being spec file, init scripts AND tmpfiles.d
Scratch the initscript. This would mean initscript would need to
contain multiple
ExecStartPre=/sbin/mkdir --mode=777 /var/run/xx; /bin/chown x.x /var/run/xx;
/sbin/restorecon /var/run/xx
lines, which look unwieldy.
So we are left with tmpfiles.d and spec file. Could the spec file be replaced
by tmpfilesd invocation in %post?
--
Tomasz Torcz To co nierealne -- tutaj jest normalne.
xmpp: zdzichubg(a)chrome.pl Ziomale na życie mają tu patenty specjalne.