bug-standards
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: /run and needing a --rundir for configure


From: Eric Blake
Subject: Re: /run and needing a --rundir for configure
Date: Thu, 05 Sep 2013 15:43:05 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8

On 09/05/2013 03:25 PM, Karl Berry wrote:
> Hi Doug,
> 
>     Subject: /run and needing a --rundir for configure
>     ...
>     The reality is that configure should add --rundir ...
>     ...
>     http://lwn.net/Articles/436012/
> 
> Interesting.
> rms will need to approve such a change to the coding standards.
> 
> Before I ask him: Stefano and autoconf-maintainers, what do you think?

As one of the autoconf maintainers, I'm in favor of the idea (hence my
proposed wording patch to make-stds.texi; I also already have a scratch
patch in my local tree for autoconf, but don't want to push it unless
the GNU Coding Standards justify its use).  Automake would also need a
tweak to add run_DATA alongside its existing localstate_DATA primary.

As explained in the lwn article, /var is for persistent runtime data,
while /run is for volatile runtime data; while systems will have to
provide /var/run as a pointer to /run for the foreseeable future (for
the sake of projects not actually built with the new --rundir support in
their configure scripts), it's better to differentiate between the
semantics up front and make it easier to change the destinations at
configure time.  And while the default should remain unchanged
(installation via --prefix=$HOME will still use $HOME/var/run if
--rundir was not specified), the existence of --rundir allows for a
system where policy does not change between a directory and its children
(Lennart has a point that having /var/run use tmpfs while /var does not
is awkward).

> The actual work on our (GNU) side would fall to you ...

Yep.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]