Re: sharedlocalstate default - does anybody use this?

[Russ Allbery]

"Mariano, Adrian V."  writes:

> 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?

Interestingly, Debian's standard tool for this doesn't override
sharedstatedir, so this will create a surprising directory the first time
the maintainer builds it (and then they'll investigate and presumably fix
it by passing in the right configure flag).  That also probably indicates
that it's very rarely used.  I think most people use localstatedir for
this sort of file, since the distinction between sharedstatedir and
localstatedir only matters for models of software installation that are
now almost extinct.

That said, I agree that it's still perfectly fine to use it.  The lack of
an override is a bug in debhelper, and units may be the prompt for us to
fix it.  :)  (Debian will almost certainly just point sharedstatedir at
the same directory as localstatedir.)

-- 
Russ Allbery (ea...@eyrie.org)  

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: sharedlocalstate default - does anybody use this?

[Eric Blake]

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

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf