As discovered in bug 177818 from the Fedora Extras, the GNU standard
directory hierarchy includes /usr/local/com as a placeholder to
store "architecture-independent data files which the programs modify
while they run" (c.f.
http://www.gnu.org/prep/standards/html_node/Directory-Variables.html)
This directory is available as $(sharedstatedir) in autoconf and
will be used by said Fedora Extras package.
It would be desirable if filesystem could own this directory.

FWIW, http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE18
"/usr is shareable, read-only data. That means that /usr should be shareable
between various FHS-compliant hosts and must not be written to."
Looks like the GNU coding standards doc is directly against the FHS in this case.

As related to the discussion the request is altered to request
/var/com
so that this can be used a a local shared state directory by default
or as a global (LAN-wide) mounting point to the sysadmins liking.

Bug 185862 was vehemently refused by Jeff Johnson with these words:
"This is a packaging, not an rpm problem. The value of
%{_sharedstatedir} has nothing whatsoever with FHS or where
emacs chooses to put files.
Fix yer bleeping packages however you want."
I will proceed to fix my bleeding package by putting something
apropriate into --with-sharedstatedir passing it to the
%configure macro.

Since RPM does not think this should be fixed, I believe either:
1. Filesystem should provide /usr/com or it will conflict default
values from RPM
2. Packaging guidelines for FC and FE should state that thou shall
never, ever use the %{_sharedstatedir}, since this refers to
a place that does not exist.

As the place for the modifiable file has been properly changed in the adplug
package you've made i will close this bug as notabug for now. /var/lib/foo is
the proper place for application specifc files and those can then be properly
owned by the corresponding packages.
Read ya, Phil

Note

You need to
log in
before you can comment on or make changes to this bug.