Bug 185862

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
disabled/broken.

Bill, views from a filesystem/distro perspective?

What exactly does emacs use it *for*?

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

Debian uses /var/lib for sharedstatedir

http://www.debian.org/doc/packaging-manuals/dpkg-internals/ch-build.html

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.

/var/lib is fine with me.

/var/lib is better if that is already in use.

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.

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...

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 
  redhat-rpm-config-8.0.40-1

  $ rpm --eval %_sharedstatedir
  /usr/com

> $ 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.

Run "grep _sharedstatedir /usr/lib/rpm/macros" and see that "rpm"
package offers the same inappropriate _sharedstatedir = /usr/com.

redhat-rpm-config is optional.

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.

REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.

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:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

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

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Still very real, so bump to Rawhide.

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

I saw this file is back in rpm from rpm-redhat-config,
so has been dormant due to that I believe?

Fixed in rpm-4.6.0-0.rc4.2.fc11, %_sharedstatedir gets set to /var/lib in the linux-platform macros now.

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.