Re: Emacs vista build failures

[Manoj Srivastava]

On Thu, 17 Jul 2008 06:23:56 +0900, Stephen J Turnbull <address@hidden> said: 

> 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*.

        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.

>> 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.

        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? 

>> > 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).

        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.

        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.

> 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.

        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.

> 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.

        Since I am actually doing all this, I can see how I can slip
 into the mistake of assuming it can be done.

        Anyway, if you do not want to engage into why normal Debian was
 of using Debianized emacsen do not work for you, and you are happy with
 your current set up, that's no skin off my nose either.

        manoj
-- 
A right is not what someone gives you; it's what no one can take from
you. Ramsey Clark
Manoj Srivastava <address@hidden> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C