Comment 10 for bug 612222

OK, Uday asked me to comment on this since I package VM for Fedora.

Here's how things work for Fedora packaging (and by extension RHEL and CentOS):

Files such as NEWS, COPYING, README and other documentation are denoted as %doc in the package spec file. What this does is say to the packaging software (i.e. rpmbuild) "These files are documentation for the package". rpmbuild then installs them in /usr/share/doc/%{packagename}-%{version}.

In other words, we don't actually make use of the way that a package installs documents natively. We really don't want to install them under some directory such as /usr/share/emacs/etc. If the upstream vm release does that we'd end up moving them anyway (this is no big deal though).

The above discussion though seems to have broadened in scope by considering where images etc should be installed. My feeling on this is that it's a problem with upstream emacs. Currently, for almost all add-on packages, everything (lisp, image files etc) is dumped into /usr/share/emacs/site-lisp/package. It would be great if there was a better directory structure for add-on packages such as:

/usr./share/emacs/site-packages
/usr./share/emacs/site-packages/lisp
/usr./share/emacs/site-packages/images
/usr./share/emacs/site-packages/etc

What would be great is if upstream promoted a directory structure for add-ons, and then all packages adopted use of that. This should also be integrated with Tom Tromey's package.el (see recent discussions on emacs-devel).

However, it would be a really bad move for VM to autonomously adopt some directory structure of its own.

S, in summary, I feel:

1/ Don't worry about installing NEWS etc - it's up to distributions to do that according to their packaging policies.

2/ Discuss with upstream emacs developers a better strategy for subdirectories for add-on packages.