Bug 183370 - Please add/own /usr/com
Please add/own /usr/com
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: filesystem (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Phil Knirsch
Mike McLean
http://www.gnu.org/prep/standards/htm...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-28 12:38 EST by Linus Walleij
Modified: 2015-03-04 20:16 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-06-28 01:23:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Linus Walleij 2006-02-28 12:38:52 EST
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.
Comment 1 Linus Walleij 2006-02-28 17:18:57 EST
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.
Comment 2 Ville Skyttä 2006-03-16 12:10:39 EST
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.
Comment 3 Linus Walleij 2006-03-16 13:22:29 EST
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...)
Comment 4 Linus Walleij 2006-03-18 07:47:50 EST
Bug submitted to FHS bugzilla to get feedback:
http://bugs.freestandards.org/show_bug.cgi?id=96

Mail sent to bug-standards@gnu.org and
freestandards-fhs-discuss@lists.sourceforge.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
Comment 5 Linus Walleij 2006-03-19 18:00:00 EST
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}
Comment 6 Linus Walleij 2006-03-20 03:56:19 EST
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.
Comment 7 Linus Walleij 2006-03-23 04:04:00 EST
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.
Comment 8 Linus Walleij 2006-03-23 04:09:49 EST
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.
Comment 9 Linus Walleij 2006-03-23 17:43:53 EST
OK I see it is moved to redhat-rpm-config and reopened...
Comment 10 Phil Knirsch 2006-06-28 01:23:14 EDT
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.