Re: Emacs vista build failures

["Stephen J. Turnbull" <stephen@xemacs.org>]

Manoj Srivastava writes:

 >         I do not think it is a typo. Debian installs an empty directory
 >  there, and never removes it; it is so that you can drop stuff in there
 >  to override the vendor installed stuff. I consider that a feature.

I guess it makes sense that /usr/local/share/emacs/site-lisp is on the
load-path when $prefix = /usr, but it causes me cognitive dissonance.
Rationale must be something like you can't go proliferating local
directories (that the admin can populate as she likes) like site-lisp
just because an application thinks that it's obviously for the use of
the admin.

As long as it's just the directory, yes, it's feature.  More than a
convenience, it tells you that it's Debian policy that you can put
stuff there and you can expect its contents to be found via load-path
(XEmacs at least prunes some directories with nothing loadable, so you
might not see it on load-path at first).

 > > That *is* crazy, and definitely hinders diagnosing bugs which are due
 > > to a mismatch between version expected and version provided by the
 > > shadowing library.  Developers and beta testers will typically have a
 > > few shadows, but in a standard installation to have *any* *is a bug*.
 > 
 > > This should be fixable by (1) linking /usr/share/emacs's .el files
 > > into the emacs-FLAVOR hierarchies, then (2) removing /usr/share/emacs
 > > from load-path.  Ditto for site-lisp.
 > 
 >         Hmm. You mean for every flavour of emacs, symlink the files from
 >  /usr/share/emacs/ hierarchy into /usr/share/<flavour> hierachy, and
 >  then drop the former? 

From load-path, yes.  Conceptually that's like a source tree, not
runnable libraries.

 > > This simply isn't sufficient, except for the case of a person
 > > maintaining one or a few Lisp packages.
[...]

 >         I have in the past maintained Gnus, and still maintain VM, and I
 >  use CVS versions of org-mode, Emacs, DVC, and a couple of other minoir
 >  emacs packages. While I might not add much of my code to htese
 >  packages, I do routinely do git pull's and compiles and use them in my
 >  almost nihtly recompiles of CVS emacs.

Which is what I said pushing one or more directories would be good
for.

 >         But hey, perhaps all the problems are indeed far above my
 >  head. It is just odd that they do not seem to  impede my playing with
 >  custom lisp code and development versions of Emacs.

I think you might have more problems with XEmacs since all XEmacsen
are expected to share the package hierarchy.

The other factor is that the problems may be beneath your notice; they
may be minor issues that a Debian maintainer deals with by not doing
stupid things (in the context of maintaining a Debian installation).
For example, Joe's point about what should and shouldn't go into
site-lisp.

 >         I am one of the people responsible for Debian policies. ANd
 >  while I am not currently active in Debian Emacs policy, I was one of
 >  the people involved in crafting it way back when.

And your authoritative suggestions for better integration might be? :-)

 >         Anyway, if you do not want to engage into why normal Debian was
 >  of using Debianized emacsen do not work for you,

Actually, I may just be about to do just that.

But for now, I'm just trying to point out that the experiences of the
two sides of this discussion are pretty much disjoint.  Until
somebody's both been deeply involved in Debian maintenance (of an
Emacs as well as some packages) and in core Emacs development, we all
have to be careful about understanding that people with different
opinions are probably basing them on different history and skills.