Re: Emacs vista build failures

[Manoj Srivastava <srivasta@ieee.org>]

On Wed, 16 Jul 2008 17:20:03 +0200, David Kastrup <dak@gnu.org> said: 

> Yes, we are all stupid.  But since the intelligent ones are rare, it
> might be worth adapting the policies to deal with the real world.

        The most common target user does not care to override Emacs
 packages for one of their own. And these are the users that Debian
 caters to well.

        But please don't construe that to mean that Debian does not
 cater to Developers, we try to.

>>> 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/
>> 
>> Frankly, I don't call that going "pretty much crazy". but it does
>> make a nice sound bite in a flamewar.

> Install a few add-on Elisp packages from Debian, then try again.

        I have. I have quite a few installed, and still, the two
 directory shadows cover everything on my machine. (cedet, gnus, vm,
 ...)


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

> First you would have to find a file which actually gets loaded instead
> of bypassed be the Debian scheme.

        My .emacs has never been bypassed. That is where I add my
 directories to the loadpath.

> Feel free to conduct a survey if you don't believe me.  I am not
> interested in being proven stupid and incapable.  I am perfectly
> willing to accept that evaluation.  But I know that I am not alone,
> and at some point of time Debian should face reality and figure out
> how to make use of all the stupid and incapable people who are
> seemingly able to get work done elsewhere.

        Hmm. I just added org-mode to
 /usr/local/share/emacs/site-lisp/org-mode,  and boom, it overrides the
 org-mode built into my emacs-snapshot package. I did absolutely
 nothing to my Debian setup to make that happen.

        Also, anything dumped into my personal lisp directorieas also
 seems to take precedence, and this is the code I use to add them (in my
 .emacs):
--8<---------------cut here---------------start------------->8---

(defvar manoj-lisp-subdirs (list "config" "functions" "bbdb"
                                 "lisp" "mail" "modes" "x-support"
                                 "debian" "news"
                                 (format "emacs%d/gnus" (emacs-major-version))
                                 (format "emacs%d/w3" (emacs-major-version))
                                 )
  "*The list of subdirtectories we want in the path.")

;;; Add the subdirs to the load path
(let ((subdirs (mapcar
                (function
                 (lambda (x)
                   (expand-file-name
                    (concat
                     my-emacs-config-dir "/"  x))))
                manoj-lisp-subdirs)))
  (while subdirs
    (let ((subdir (car subdirs)))
      (if (not (member subdir load-path))
          (setq load-path (cons subdir load-path))))
    (setq subdirs (cdr subdirs))))
--8<---------------cut here---------------end--------------->8---

        So, really, unless I can reproduce the problem you claim to
 have, I can't file bug reports, not can I figure out a scheme to fix
 them.

        From where I sit, at least my bog standard Debian unstable
 distribution does not get in my way when trying to maintain my emacs
 lisp packages. I am sorry your mileage has varied.

        manoj
-- 
Biz is better.
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C