Bug 183370

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