From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Manoj Srivastava Newsgroups: gmane.emacs.devel Subject: Re: Debian's idiosyncratic complexification of Emacs Date: Wed, 16 Jul 2008 17:26:42 -0500 Organization: Manoj Srivastava's Home Message-ID: <87bq0xihy5.fsf@anzu.internal.golden-gryphon.com> References: <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> <20080714223059.GG3445@muc.de> <8763r858dx.fsf@uwakimon.sk.tsukuba.ac.jp> <85ej5vbpzm.fsf@lola.goethe.zz> <87iqv5kiy5.fsf@anzu.internal.golden-gryphon.com> <87iqv5wogs.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1216247251 2484 80.91.229.12 (16 Jul 2008 22:27:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 16 Jul 2008 22:27:31 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 17 00:28:19 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 1KJFTu-00080q-BY for ged-emacs-devel@m.gmane.org; Thu, 17 Jul 2008 00:28:18 +0200 Original-Received: from localhost ([127.0.0.1]:42566 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KJFT1-0002Cu-PN for ged-emacs-devel@m.gmane.org; Wed, 16 Jul 2008 18:27:23 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KJFSb-0001qm-1R for emacs-devel@gnu.org; Wed, 16 Jul 2008 18:26:57 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KJFSa-0001q0-3u for emacs-devel@gnu.org; Wed, 16 Jul 2008 18:26:56 -0400 Original-Received: from [199.232.76.173] (port=38198 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KJFSZ-0001ph-UO for emacs-devel@gnu.org; Wed, 16 Jul 2008 18:26:55 -0400 Original-Received: from main.gmane.org ([80.91.229.2]:58024 helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KJFSZ-00036v-7e for emacs-devel@gnu.org; Wed, 16 Jul 2008 18:26:55 -0400 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KJFST-0008BE-2U for emacs-devel@gnu.org; Wed, 16 Jul 2008 22:26:49 +0000 Original-Received: from tiamat.golden-gryphon.com ([204.117.95.118]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 Jul 2008 22:26:49 +0000 Original-Received: from srivasta by tiamat.golden-gryphon.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 Jul 2008 22:26:49 +0000 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 83 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: tiamat.golden-gryphon.com User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) (x86_64-unknown-linux-gnu) Face: iVBORw0KGgoAAAANSUhEUgAAACYAAAAwCAMAAABKbPgaAAAAM1BMVEUAAADIjH/0rp1KPz79 0b+ic2nlpJc2Ly2AY17VlYb4uqi2gHQXFBN2WVXgno5iT02Xa2Nx+jaIAAACVElEQVQ4jeWU23bj IAxFLUAggQX6/6+dI9LGTpo+9mlYiXNhc3TnOP50naZE0tqvgEk+soutnNfQ8yPTWMTENhNrjI+Y +N7POVt8tAzpn2vJlsmttbyfrdkP7hx5iezteGzsbOts7xT+tC1mcG+LtRP2X/16bEQExuyx1uZW vscrAWUT8aE0aDBeBuw8nS5u4WgWyDCllOZUBeyWgbWbGrBsTDpTx0qpphlcYPcgJLvBXFClPMg5 6WH2JidLIAaDF5aAed7uPTH4bjw0bZvfajp2tHc1F+cBm+Vr9YomGSwNhbmcczYEWUu5MBpYvCLV F+ZIKwQfYB+CBXnIRQFvIRhK6l96PemsFLEPFxi+MPxiTYH0Ave1InPsIYes3NJb42ytBSmmysyj lIQYHJm6Im1WbQ0kWMesKFRFPKTDzJ3GhWUn2KWKEkWlKthoACLm2eWJQQh2qKbAUgQxa+8TVjn1 aySm8656ookCfCc5TRzvnZ6YOu3NpHg+uR5YuRkNF/b5IHq5Y7Ve6c2+sR4hqIZ3+5DCt3ukh8Eo vFIXVJxqfMdbkd/BF3YaQkB/2RIUHPMS7RLVAHefrYzWZVQ/ei4peBsROFLi90ltQyvF5I05t4Zs L4C9DODJ2AZCUf8UitGjCIdfx15QQkfZibTOGT3edxns5fY6F2rstKcTwiiaJnQwvYkdzTlaTqNH IkSmGdLrON45tGsMNDoSYr4bxH5emHEFaoFjKBahHXFXfLx9cR9p6ejJXihuxPz57gWHZkWovbPl 9gsU8eImtBi++3D+f+sfT/Mg79fyEz8AAAAASUVORK5CYII= X-URL: http://www.golden-gryphon.com/ Mail-Copies-To: never X-Face: #q.#]5@vq!Jz+E0t_/; Y^gTjR\T^"B'fbeuVGiyKrvbfKJl!^e|e:iu(kJ6c|QYB57LP*|t &YlP~HF/=h:GA6o6W@I#deQL-%#.6]!z:6Cj0kd#4]>*D, |0djf'CVlXkI, >aV4\}?d_KEqsN{Nnt7 78"OsbQ["56/!nisvyB/uA5Q.{)gm6?q.j71ww.>b9b]-sG8zNt%KkIa>xWg&1VcjZk[hBQ>]j~`Wq Xl,y1a!(>6`UM{~'X[Y_,Bv+}=L\SS*mA8=s;!=O`ja|@PEzb&i0}Qp,`Z\:6:OmRi* Cancel-Lock: sha1:pQq0ZE+gYLcV8lNaSjcUsjBFSP0= X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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:100848 Archived-At: On Thu, 17 Jul 2008 05:42:11 +0900, Stephen J Turnbull said: > Manoj Srivastava writes: >> On Tue, 15 Jul 2008 08:50:21 +0200, David Kastrup said: >> >> > No, you don't understand: byte-compiled files should not go into >> > /usr/local/share/emacs/site-lisp. This directory is only >> > incidentally named like a standard Emacs search path directory. >> > The byte-compiled files are to be in another directory so that >> > list-load-path-shadows has something to think about. >> >> Which directory is that? > People here (with the exception of Stefan) have been very incautious > about distinguishing $prefix, /usr, and /usr/local. Is that the issue > you refer to? >> > And of course, any package installation that thinks it might work >> > by placing .elc in the same place as .el is naive. >> >> Assuming you are not just trying to pick a fight, the problem that >> needs to be solved is this: > Emacs users and Emacs itself assume that the source for a compiled > library can be found in the same directory as the library itself. If > as you and David imply, this is not true, the Debian installation > breaks standard practices of a great many long-time Emacs users. > These practices are taught to new users, too. > IOW, you've specified the problem incorrectly, at least if you want to > serve the traditionalists satisfactorily. Pardon me, I do think I know the problem that Debian was trying to solve when they implemented this mechanism. Yes, it does break the expectation that the .el and .elc files live in the same location; I'll see what can be done to correct that, while still addressing the problem that does need to be solved for Debian users (by adding symlinks as David noited is the right thing to do). > The problem (for Debian) that you describe is real, and important. > There are an awful lot of Debian users who just want Emacsen to work, > and who keep all their personal development in .emacs, until it gets > accepted to the mainline. There are multi-user, multi-Emacs hosts, > and certainly Lisp package maintainers need them. The system works > well for them AFAICS, with the exception that some XEmacs users want > to use a few XEmacs packages from our archive, and that doesn't mix > well with a Debian installation. Actually, I just add whole subdir trees (for a site-wide install) in /usr/local/share/emacs/site-lisp or add to the loadpath in .emacs (for a personal installation); which is slightly different than keeping all the code in .emacs. > However, trying to work with a Debianized X?Emacs in Emacs development > certainly creates a substantial burden. Joe made the point that a lot > of stuff that's in many site-start.els doesn't belong there. Well, > yes and no. On my personal system, it *is* *my* site, and if I choose > to organize my .emacs by putting stuff that's relevant to all my users > in site-start, and stuff that's relevant only to root, mailman, > postgres, and my personal user respectively in .emacs, it is none of > Debian's business. Right. Nothing will ever edit or modify anything you put in /etc/emacs/site-start.el. > Debian's load-path and .d startup infrastructure is pretty baroque > (though easy to understand once you understand the .d startup > infrastructure in *any* context). Navigating it in case of a bug that > manifests in a Debian install can be quite annoying. > Sure, it can be worked around, but I found it too great a burden for > the benefits, considering that most of the work would be duplicated by > Debian's Lisp package maintainers anyway. Sure. I am just puzzled as to why I am not experiencing _any_ of these issues. If I could reproduce some of the issues, perhaps I can do my bit to solve the problem for other folks too. manoj -- Virtue is a relative term. Spock, "Friday's Child", stardate 3499.1 Manoj Srivastava 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C