Re: Emacs vista build failures

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

Manoj Srivastava writes:

 > > As one consequence, the diagnostic tool M-x list-load-path-shadows RET
 > > pretty much goes crazy on Debian.
 > 
 >         It is:
 > A. /usr/share/<current-emacs-flavour> hiding /usr/share/emacs
 > B. /usr/local/share/emacs/site-lisp/<current-emacs-flavour> hiding 
 >                                    /usr/share/emacs/site-lisp/

Is that "local" a typo?  If not, I consider it a bug.  IMO Debian
should never install anything (except maybe the standard list of
subdirectories) into /usr/local; that's *mine*.

 >         Frankly, I don't call that going "pretty much crazy". but it
 >  does make a nice sound bite in a flamewar.

Well, I can infer that you just don't care about shadows, because that
means that essentially all libraries have shadows.

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.

 > > The only sane way out is to compile and manage your own Emacs and
 > > packages.  And that's what _all_ Emacs and XEmacs developers I know
 > > who are not simultaneously Debian maintainers do.
 > 
 >         I think this is not the case, since a trivial work around is
 >  available (add your dir to the head of the path).

This simply isn't sufficient, except for the case of a person
maintaining one or a few Lisp packages.  Don't bother asking for
details; that's the product of experience with many small confusing
problems, and if I *could* characterize the many confusingly small
problems anything like that simply, I would have tried to fix those
confusingly many small problems (all alike ;-), and probably I'd still
be using Debianized Emacsen.  The best I've heard of is Miles's hack,
but he apparently uses a non-Debianized Emacsen and a .emacs hack
which adds /usr/share/emacs to his load-path (and I bet it's not at
the head).

In other words, you're making the same mistake that Alan did.  Because
the set of people who actively participate in Emacs (and XEmacs)
development on a day-to-day basis does not AFAICT include the Debian
Emacsen maintainers and especially those who maintain the Debian Emacs
Policy, there is nobody who can speak authoritatively about how the
DEP and Emacs development practice could be better integrated.

Nevertheless, you and Joe extrapolate from personal experience and
assume that since you don't run into problems, a little discipline
would solve them for the developers, too.  That's just as wrong as
Alan assuming that with a little more care the DEP could be adjusted
so that he could use a Debianized Emacs in his usual way.