[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[xemacs21*.deb] [FHS] Which is the real xemacs/site-lisp{,-21}?

 [ Re: xemacs21*_21.1.*.deb packages by James LewisMoss <dres@debian.org> ]

 I notice there are both "/usr/{lib,share}/xemacs/site-lisp{,-21}"
 directories installed[1].  Which one are folks who've installed the
 package supposed to use?  I'd say the one in share...  Which one does
 the XEmacs-21.1.8 debian package expect?  Below, I propose a better,
 IMO, `load-path'.

 Answering my own question, I see that `load-path' is: [ abridged ]


 Hmmm... some end in "/", others don't.  I bet it doesn't matter... as
 long as any codes that use the elements of `load-path' call
 `file-name-as-directory' on them to canonicalize.  Many of these have
 been pushed on the `load-path' by the "/etc/{x,}emacs/{*,}/site-start.d"

 The main idea is that lisp codes meant for the more specific
 `emacs-version', ${configuration} and/or ${hostname} are car-end
 `load-path', and the more portable/general codes cdr-end, so you can
 drop in a repaired version of something that doesn't work without a
 patch, doesn't work in $EMACS <= $VERSION, should be available only
 on a certain architecture or host, or shadow them with enhanced
 versions; whatever you require or prefer.  The lisp codes'
 installation location is up to the .deb package that installs the
 lisp codes (or shared-object plugin, on `module-path', iirc, l8r
 w/21.2).  Put the `packages' lisp ahead of `site-lisp', since that's
 often XEmacs-patched (and "site-lisp" is considered deprecated now
 for XEmacs >= 21.1, right?) and put the "~/.xemacs/*" [2] stuff ahead
 of everything else so a user can override anything on the system at
 will.  I think that the mule specific codes ought shadow the other
 codes, along the way down `load-path'. (see the order I have them in

 We use "/usr/{local/,}/share" in preference to "/usr/{local/,}/lib"
 for reasons outlined in the Linux Filesystem Heirarchy Standard
 (FHS).  (Think NFS/SAMBA shares.)

 Maybe we need a load-path sorter function to be called after all of
 the "/etc/{xemacs{/21{.1,},},emacs}.d files" [3] are run?  Or a
 `deb-load-path-insert'?  What do yous think?  It might be faster and
 most convenient to sort them once at the end, with
 "/etc/xemacs/${SHORT_VERSION}/\ site-start.d/99pathsort.el".  Note
 that with XEmacs >= 21.1, the "auto-autoloads.el" mechanism mostly
 obviates the need for the "/etc/xemacs/*/site-start.d" files.  Those
 files could (maybe --- I've not tested it.) simply contain
 `custom-file' settings, if all they do is initialize variables....
 Comments or ideas on this?  (Themes will be way cool. ;-)

 What I think I'd try and make it look along, in order, for
 `load-path', follows.  This will likely have to be done via the
 debian specific "site-start.el" (which runs everything in
 "/etc/{x,}emacs/*/site-start.d" in a specific order) mechanism, and
 not via the standard `load-path' initialization setup by
 "{startup,paths}.el".[4] We'd override the upstream `load-path' setup
 codes, and roll our own FOR NOW.  The paths passed to `configure'
 will just be seed values, to make `xemacs -vanilla' work as expected.
 The XEmacs startup code path needs to be followed, brain-run and
 maybe worked on some, IMO... (my custom settings for
 `default-x-frame-plist' don't take effect until I create the second
 frame.  Very annoying.  It's a ToDo.)  Anyway, here's my idea of what
 `load-path' maybe should contain, in order.

     ;; User can shadow anything.
     ~/.xemacs{/21{.1,},}/{{mule-,}packages/,}lisp{/karlheg,}/ ; [5]
     ~/.gnulisp/ ; ?  Is this commonly used out there?  I saw it someplace...

     ;; /usr/local/share is first, so the sysadmin can shadow
     ;; anything, or drop in site or host local codes.
     /usr/local/share/xemacs/{21{.1,}/,}site-lisp/ ; deprecated ?

     ;; Debian packages install lisp codes under /usr/share.

 Trying to figure out where to put something would be less confusing
 this way...  A README belongs in "/usr/{local/,}share/xemacs", as
 well as in "/usr/share/doc/xemacs*".  I guess the ones in the lisp
 directories ought to be symlinks to the one in doc.  There should be
 no non-architecture-dependant codes under "/usr/lib/xemacs/*" at all.

 I would not even ship the dumped .elc files; but would ship their .el
 files in the supportel or whatever.  You'll need the source package
 to custom-redump anyhow.  Perhaps much of the "etc/" directory could
 be left behind in the source package as well, maybe with a
 "replacement" README in there explaining where to find them.  It's
 way easy to run `apt-get source' now.

 There will probably need to be a debconf-displayed warning message or
 (bluck, just don't hang and wait for me to press a key) preinst
 message iff there are files in the (deprecated) site-lisp
 directories?  Hmmm.  We need to think that over some.
 `install-emacs' will need an update for all of this to work,

 Any comments or ideas?  Please discuss it with everyone on
 debian-emacsen!  You are invited to subscribe at
 debian-emacsen-request@lists.debian.org. (smartlist).  It's been, so
 far, a very low-traffic list.

Karl M. Hegbloom <karlheg@debian.org>

 [ By the way, I'm still hacking on my build and packaging setup for
   XEmacs, working with XEmacs-21.2-beta.  These days, I'm learning
   all I can about CVS (`bitkeeper' sounds cool too... haven't tried
   it yet.)  Maybe someday soonish (3 months, minimum) I'll finish it
   and upload it to experimental, ifwhen.please() I have permission
   from the xemacs-beta team && it actually builds and runs, else,
   I'll try and see about releasing to unstable with XEmacs-21.2.

   I remember the "flame-war" last summer, and will think up a good
   way to make things work nicely both for folks who want to use
   "~/.emacs" and those who prefer "~/.xemacs/init.el" or somesuch.
   Hey, if you want your GNU Emacs to bomb on XEmacs specific
   `customize' options, go for it.  It's your life.  In the source
   package, I will make it possible to easily define customized
   configurations and dumped-lisp sets, something like `make-kpackage'
   for XEmacs. ]

[1] Listed in the xemacs21-basesupport.list files.

[2] Another debate was whether it ought to be "~/.xemacs" or "~/xemacs".

[3] In that order too, I think.

[4] Note the literal `~', not expanded to the builders home
    directory. <grin> Don't you hate those kind of silly errors?  It's
    2am, and ten minutes after the release upload, and I just realized

[5] This belongs in /etc/skel, with a README under it explaining
    things, along with a Makefile that recreates
    "auto-autoloads.el{,c}" and "custom-load.el{,c}" in there.
    **There needs to be a mechanism where when a package drops new or
    modified conffiles into "/etc/skel", it will notify all users of
    the new files, so they can `cp' or `ediff'.

Reply to: