Bug 183370 - Please add/own /usr/com
Summary: Please add/own /usr/com
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: filesystem   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Phil Knirsch
QA Contact: Mike McLean
URL: http://www.gnu.org/prep/standards/htm...
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-02-28 17:38 UTC by Linus Walleij
Modified: 2015-03-05 01:16 UTC (History)
2 users (show)

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


Attachments (Terms of Use)

Description Linus Walleij 2006-02-28 17:38:52 UTC
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 22:18:57 UTC
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 17:10:39 UTC
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 18:22:29 UTC
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 12:47:50 UTC
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 23:00:00 UTC
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 08:56:19 UTC
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 09:04:00 UTC
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 09:09:49 UTC
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 22:43:53 UTC
OK I see it is moved to redhat-rpm-config and reopened...

Comment 10 Phil Knirsch 2006-06-28 05:23:14 UTC
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.