Re: mh-e for emacs-snapshot and icon images directory
Peter S Galbraith <p.galbraith@globetrotter.net> wrote:
> Romain Francoise <rfrancoise@debian.org> wrote:
>
> > Peter Galbraith <GalbraithP@dfo-mpo.gc.ca> writes:
> >
> > > Secondly, the icon images have been moved out of the elisp directory in
> > > CVS Emacs and into
> > >
> > > /usr/share/emacs/VERSION/etc/images/
> > >
> > > For the mh-e package, I have placed them into
> > >
> > > /usr/share/emacs/site-lisp/etc/images/mh-e/
> > >
> > > but I am being lobbied to place them into simply
> > >
> > > /usr/share/emacs/site-lisp/etc/images/
> > >
> > > for symmetry and for later sharing with other packages. Would people
> > > object to me populating a site-lisp directory with so many files
> > > directly? I'm on the fence about this. On one side, I like the
> > > symmetry with how Emacs bundles them; on the other I don't like the
> > > apparent added clutter in the site-lisp directory.
> > >
> > > Any thoughts?
> >
> > In Debian, /usr/share/pixmaps is the correct location for image
> > files[1], so you should put images under /usr/share/pixmaps/mh-e/ and
> > populate /usr/share/emacs/site-lisp/etc/images/mh-e with symlinks (see
> > how gnus does it).
Just out of curiosity, what's the difference between /usr/share/icons
and /usr/share/pixmaps? I couldn't find anything in either the FHS or
Debian policy docs.
> I was wondering why the gnus package did that. I hate symlink farms,
> but if that's policy...
>
> > As for 'etc/images' vs 'etc/images/mh-e', I think having the
> > subdirectory is cleaner. It avoids theoretical issues with two packages
> > providing the same file, etc.
Romain, the new Emacs policy is to fully qualify images relative to
etc/images and packages are required to put their package-specific
images in a sub-directory (unless they don't have enough to justify a
sub-directory as is the case with MH-E) so collisions are no longer
possible. If two packages refer to the same file, they mean to share it.
If Gnus used the common Emacs images, or the mail ones (encouraged),
then I would imagine they would want to put these directly in etc/images
too. When this comes to pass, it would probably be good to create a common
Emacs image package.
If they put the images in the gnus sub-directory, then they would have
to move the images currently in etc/images/gnus into
etc/images/gnus/gnus which seems messy and would break their code that
finds the image directory relative to the Gnus library.
Another reason for putting the images directly in etc/images is that it
simplifies the Debian package configuration. Currently, Peter adds the
etc/images/mh-e directory to the load-path for Emacs 21 and
image-load-path (new) in Emacs 22. If the images were in etc/images
directly, and the MH-E library was in
/usr/share/emacs/site-lisp/mh-e/lisp, then our code would find the image
directory automatically (like Gnus).
I also notice that gnus-tut.txt is directly in
/usr/share/emacs/site-lisp/etc/, not in
/usr/share/emacs/site-lisp/etc/gnus. In other words, the Gnus package
reflects the Emacs hierarchy in all ways. So should the MH-E package.
Please see
http://savannah.gnu.org/cgi-bin/viewcvs/emacs/emacs/etc/images/
for the current image structure in Emacs itself. Note that I'm moving
all of the images in lisp/toolbar to etc/images today.
Check out
http://thread.gmane.org/gmane.emacs.devel/42684
for some history.
In summary, etc/images/mh-e is inconsistent with CVS Emacs and with the
Gnus Debian package. The rationale for it is based upon a concern that
no longer exists with current Emacs policy.
--
Bill Wohler <wohler@newt.com> http://www.newt.com/wohler/ GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.
Reply to: