[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: sharedlocalstate default - does anybody use this?
From: |
Eric Blake |
Subject: |
Re: sharedlocalstate default - does anybody use this? |
Date: |
Wed, 6 Jun 2018 07:47:18 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 |
On 06/06/2018 07:09 AM, Mariano, Adrian V. wrote:
It has been brought to my attention that in my package (GNU units) I have a
file that gets changed every day located in datarootdir---but this location is
for read only files.
The correct place for my architecture independent dynamic file would appear to be
sharedstatedir. However, this resolves to the rather bizarre path /usr/local/com. I
can't find any reference to anybody actually using this path. Do all the distributions
over-ride this into something "normal"?
Distros are not allowed to install into /usr/local. So a default of
/usr/local/com is irrelevant to them - but still relevant to a
non-distro build.
The fedora units guy tells me it will be /var/lib, for example---and I think
with redhat the whole /usr directory is supposed to be read only.
Top-level /usr might be read-only, but distros don't control /usr/local.
So what's the correct practice for my package? Should I use sharedstatedir and
not worry about it resolving to a strange default path because mostly it will
get changed by site defaults?
Correct. Under the /usr/local hierarchy (when you install the software
yourself as an add-on to the distro packaging), /usr/local/com is better
than any other alternative, for still being located within a single
hierarchy under your control. But under the /usr hierarchy (when the
software is installed on your behalf by the distro), /var/lib is correct
- but that's WHY './configure --sharedstatedir=/var/lib' exists, and
distros are responsible for setting it.
Or is there some other way to handle this?
No, as long as you use sharedstatedir correctly, then you don't have to
take care of anything further.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org