Peter S Galbraith <[EMAIL PROTECTED]> wrote: > Romain Francoise <[EMAIL PROTECTED]> wrote: > > > Peter Galbraith <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
