Bug 185862 - %_sharedstatedir violates the FHS
Summary: %_sharedstatedir violates the FHS
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Panu Matilainen
QA Contact: Fedora Extras Quality Assurance
Whiteboard: bzcl34nup
Depends On:
TreeView+ depends on / blocked
Reported: 2006-03-19 22:58 UTC by Linus Walleij
Modified: 2009-02-24 20:52 UTC (History)
8 users (show)

Fixed In Version: 4.6.0-1.fc10
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-01-31 12:01:27 UTC
Type: ---

Attachments (Terms of Use)

Description Linus Walleij 2006-03-19 22:58:46 UTC
As discussed in bug 183370 and on the Fedora Extras
mailinglist, we have come to the conclusion that the fact
that in /usr/lib/rpm/macros
%{_sharedstatedir} resolves into ${_prefix}/com and that
does not comply with the FHS.

Please change this from ${_prefix}/com to simply /var, which
is the conclusion we have come to actually solves this for the

Comment 1 Linus Walleij 2006-03-20 08:59:27 UTC
Just using /var is not so good, since the idea of ${_sharedstatedir}
is to have data sharable across computers, and /var will be
local to one certain machine.

/var/com is a better choice, so that admins can choose to mount this
across a LAN using e.g. NFS.

FYI: EMACS apparently uses $sharedstatedir which means, that since this
directory does not exist in the filesystem package, that feature is

Comment 2 Paul Nasrat 2006-03-20 14:46:16 UTC
Bill, views from a filesystem/distro perspective?

Comment 3 Bill Nottingham 2006-03-20 18:43:26 UTC
What exactly does emacs use it *for*?

Having writable stuff contained solely under /var is a good idea.

Comment 4 Paul Nasrat 2006-03-20 18:55:22 UTC
Debian uses /var/lib for sharedstatedir


Others use /var/cache, I'm happy with undere /var it's just do we want /var/com
or should we use something already existing.

Comment 5 Bill Nottingham 2006-03-20 20:34:12 UTC
/var/lib is fine with me.

Comment 6 Linus Walleij 2006-03-20 21:05:21 UTC
/var/lib is better if that is already in use.

Comment 7 Jeff Johnson 2006-03-23 01:32:33 UTC
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.

Comment 8 Linus Walleij 2006-03-23 09:13:21 UTC
For clarifiction, since we are refering to bug 183370 I assume that
the "bleeding package" you so strikingly refer to here is the
Fedora "filesystem" package?

BTW: Thank you for your diplomatic and well-balanced feedback on this issue...

Comment 9 Michael Schwendt 2006-03-23 15:09:28 UTC
Dear Mr. Jeff Johnson,

may I kindly ask you to be less destructive? This _is_ an rpm
problem actually, because of default globals, which apparently
don't fit into the rest of the Fedora filesystem setup:

  $ rpm -qf /usr/lib/rpm/redhat/macros 

  $ rpm --eval %_sharedstatedir

Comment 10 Michael Jennings (KainX) 2006-03-23 15:16:32 UTC
> $ rpm -qf /usr/lib/rpm/redhat/macros 
> redhat-rpm-config-8.0.40-1

"redhat-rpm-config" and "rpm" are not the same thing.  Thanks for playing, though.

Comment 11 Michael Schwendt 2006-03-23 15:21:50 UTC
Run "grep _sharedstatedir /usr/lib/rpm/macros" and see that "rpm"
package offers the same inappropriate _sharedstatedir = /usr/com.

redhat-rpm-config is optional.

Comment 12 Michael Jennings (KainX) 2006-03-23 15:37:13 UTC
Your point being?

Your complaint is with the Fedora configuration for rpm, not rpm.  rpm is a
cross-platform tool which is not bound by the FHS.

Comment 13 Red Hat Bugzilla 2007-02-05 19:08:40 UTC
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.

Comment 14 Bug Zapper 2008-04-03 17:09:14 UTC
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Comment 15 Bug Zapper 2008-05-14 02:07:20 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:

Comment 16 Linus Walleij 2008-12-01 23:46:35 UTC
Still very real, so bump to Rawhide.

Comment 17 Linus Walleij 2008-12-01 23:52:28 UTC
So to clarify I belive the bug would be resolved by this line in /usr/lib/rpm/macros:

%_sharedstatedir        %{_prefix}/com

to this:

%_sharedstatedir        %{_prefix}/var/lib

Comment 18 Linus Walleij 2008-12-01 23:54:25 UTC
I saw this file is back in rpm from rpm-redhat-config,
so has been dormant due to that I believe?

Comment 19 Panu Matilainen 2009-01-31 12:01:27 UTC
Fixed in rpm-4.6.0-0.rc4.2.fc11, %_sharedstatedir gets set to /var/lib in the linux-platform macros now.

Comment 20 Fedora Update System 2009-02-24 20:51:45 UTC
rpm-4.6.0-1.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

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