From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Emacs vista build failures Date: Wed, 16 Jul 2008 17:20:03 +0200 Message-ID: <86r69tonz0.fsf@lola.quinscape.zz> References: <4eb0089f0807111217m66d6cf4el777c197c107ce034@mail.gmail.com> <87skug6tq5.fsf@catnip.gol.com> <4eb0089f0807111345h13eccdds9b2cf43370b94074@mail.gmail.com> <4eb0089f0807121340x5e26f6dbve03ef50b238f3a3a@mail.gmail.com> <87k5fph5rh.fsf@stupidchicken.com> <20080713214648.GB1076@muc.de> <487A783B.7060603@gmail.com> <20080713232635.GD1076@muc.de> <85od51id2t.fsf@lola.goethe.zz> <20080714204242.GH6711@volo.donarmstrong.com> <85k5foch2r.fsf@lola.goethe.zz> <87ej5tkia0.fsf@anzu.internal.golden-gryphon.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1216221668 5961 80.91.229.12 (16 Jul 2008 15:21:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 16 Jul 2008 15:21:08 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 16 17:21:55 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KJ8oT-0003xR-Kp for ged-emacs-devel@m.gmane.org; Wed, 16 Jul 2008 17:21:05 +0200 Original-Received: from localhost ([127.0.0.1]:49213 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KJ8nb-0004Wp-1d for ged-emacs-devel@m.gmane.org; Wed, 16 Jul 2008 11:20:11 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KJ8nW-0004WO-G5 for emacs-devel@gnu.org; Wed, 16 Jul 2008 11:20:06 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KJ8nV-0004W4-Mc for emacs-devel@gnu.org; Wed, 16 Jul 2008 11:20:06 -0400 Original-Received: from [199.232.76.173] (port=42019 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KJ8nV-0004W1-JC for emacs-devel@gnu.org; Wed, 16 Jul 2008 11:20:05 -0400 Original-Received: from mail.quinscape.de ([212.29.44.217]:39395) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KJ8nU-0000dX-UT for emacs-devel@gnu.org; Wed, 16 Jul 2008 11:20:05 -0400 Original-Received: (qmail-ldap/ctrl 12627 invoked from network); 16 Jul 2008 15:20:03 -0000 Original-Received: from unknown (HELO lola.quinscape.zz) ([10.0.3.43]) (envelope-sender ) by quinx.quinscape.de (qmail-ldap-1.03) with SMTP for ; 16 Jul 2008 15:20:02 -0000 Original-Received: by lola.quinscape.zz (Postfix, from userid 1001) id DF1128F046; Wed, 16 Jul 2008 17:20:03 +0200 (CEST) In-Reply-To: <87ej5tkia0.fsf@anzu.internal.golden-gryphon.com> (Manoj Srivastava's message of "Wed, 16 Jul 2008 09:36:39 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-AntiVirus: checked by AntiVir MailGate (version: 2.1.3-2; AVE: 7.8.0.68; VDF: 7.0.5.126; host: quinx) X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:100812 Archived-At: Manoj Srivastava writes: > On Mon, 14 Jul 2008 23:05:16 +0200, David Kastrup said: > >> Don Armstrong 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/ hiding /usr/share/emacs > B. /usr/local/share/emacs/site-lisp/ 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