emacs-devel
[Top][All Lists]
Advanced

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

Re: Emacs vista build failures


From: David Kastrup
Subject: Re: Emacs vista build failures
Date: Wed, 16 Jul 2008 17:20:03 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

Manoj Srivastava <address@hidden> writes:

> On Mon, 14 Jul 2008 23:05:16 +0200, David Kastrup <address@hidden> said: 
>
>> Don Armstrong <address@hidden> writes:
>>> On Mon, 14 Jul 2008, David Kastrup wrote:
>>> 
>>>> I know of _no_ upstream Emacs or XEmacs developer who claims to
>>>> understand or get along with the Debian setup.
>>> 
>>> There's no need for upstream developers to bother, since it's all
>>> handled for them by Debian Developers.
>
>> Uh, upstream developers need to compile and test their work, too.  And
>> it is not feasible to, say, arrange your own package in front of the
>> load-path somewhere in /usr/local/ since the Debian policy puts .el
>> files and .elc files in completely different directory hierarchies
>> (and different places in the load-path order), so things tend to get
>> mixed up if they are more than once in the load-path.
>
>         Why does that matter for you in /usr/local? You can put all the
>  .el and .elc files in the same directory. As an emacs developer, surely
>  you can put a path in front of the system load path? I mean, a
>  dumb-as-doornails Debian person like me can  manage to add my elisp
>  directories ahead of system paths, so surely an intelligent emacs
>  developer can do so as well, unless they wanted to appear unable for
>  the sake of a debating point.

I am not an intelligent Emacs developer.  And it would appear that there
are pretty few of either them or intelligent XEmacs developers around.
Again: I know of no upstream Emacs or XEmacs developer that is able to
work with the Debian setup.

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.

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

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

Anyway, we are on the Emacs developer list.  So if I am talking nonsense
about Emacs developers, you'd expect to hear a correction.  And the same
discussion has been on the XEmacs developer list.

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.

-- 
David Kastrup




reply via email to

[Prev in Thread] Current Thread [Next in Thread]