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.
Hm, sorry for confusion here but it should actually be both of these: /usr/com /usr/local/com the first will be used by packaged RPMs the second by stuff compiled from source and the same old drill.
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.
Ho hum that's something... In a fight between GNU directory structure and Linux FHS who would win? Score from Googlefight: "GNU Coding Standards": 892,000 results "Filesystem Hierarchy Standard": 1,500,000 results FHS WINS! (Sorry I could not resist this, we need to have fun too...)
Bug submitted to FHS bugzilla to get feedback: http://bugs.freestandards.org/show_bug.cgi?id=96 Mail sent to bug-standards and freestandards-fhs-discuss.net to raise input (if you know of some better way to reach the GNU CS people then please inform us): As has been found in the Fedora Core bugzilla, we discovered a conflict between the GNU Coding Standards and FHS. Quoting FHS: (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." Quoting GNU Coding Standards: (http://www.gnu.org/prep/standards/html_node/Directory-Variables.html) "'sharedstatedir' The directory for installing architecture-independent data files which the programs modify while they run. This should normally be /usr/local/com, but write it as $(prefix)/com. Since the latter will resolve into /usr/com if $prefix is /usr (which is common when building a package for a system), a conflict arise, where FHS says it should not be written to, whereas GNU CS says it is even recommended to do so, provided the data is architecture-independent. Could this issue be resolved? I know $sharedstatedir is somewhat obscure, but not we have a program actually using it. Please visit our Bugzilla ticket for this if you have the time: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183370
After comments from Ralf Corsepius that this is probably just an RPM macro problem I have filed bug 185862 to see if we can relocate %{_sharedstatedir}
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.
OK I see it is moved to redhat-rpm-config and reopened...
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