From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Debian's idiosyncratic complexification of Emacs Date: Thu, 17 Jul 2008 05:42:11 +0900 Message-ID: <87iqv5wogs.fsf@uwakimon.sk.tsukuba.ac.jp> 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1216240109 11019 80.91.229.12 (16 Jul 2008 20:28:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 16 Jul 2008 20:28:29 +0000 (UTC) Cc: emacs-devel@gnu.org To: Manoj Srivastava Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 16 22:29:17 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 1KJDcZ-0006rd-EB for ged-emacs-devel@m.gmane.org; Wed, 16 Jul 2008 22:29:07 +0200 Original-Received: from localhost ([127.0.0.1]:34544 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KJDbg-00085w-T5 for ged-emacs-devel@m.gmane.org; Wed, 16 Jul 2008 16:28:12 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KJDbS-0007yG-Ea for emacs-devel@gnu.org; Wed, 16 Jul 2008 16:27:58 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KJDbQ-0007wN-Js for emacs-devel@gnu.org; Wed, 16 Jul 2008 16:27:58 -0400 Original-Received: from [199.232.76.173] (port=44988 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KJDbQ-0007wA-AJ for emacs-devel@gnu.org; Wed, 16 Jul 2008 16:27:56 -0400 Original-Received: from mtps02.sk.tsukuba.ac.jp ([130.158.97.224]:58224) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KJDbP-0006H1-Ou for emacs-devel@gnu.org; Wed, 16 Jul 2008 16:27:56 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps02.sk.tsukuba.ac.jp (Postfix) with ESMTP id AF0CA8003; Thu, 17 Jul 2008 05:27:53 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 340AA1A25C3; Thu, 17 Jul 2008 05:42:11 +0900 (JST) In-Reply-To: <87iqv5kiy5.fsf@anzu.internal.golden-gryphon.com> X-Mailer: VM ?bug? under XEmacs 21.5.21 (x86_64-unknown-linux) 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:100837 Archived-At: 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. > > And Emacs has a command byte-recompile-directory just by mistake. > > Emacs makes no attempt to cater to the issues facing third party > elisp packages, so someone has to pick up where emacs developers stop. > I have emacs 21, emacs 22, emacs-snapshot, and the latest XEmacs on > this machine, and I also keep a non-debian git checkout emacs in > /usr/local, and I have VM working flawlessly for all these flavours. > > If you have a better idea on how this should be done, please, I > am all ears. Snarky remarks really do not help. I don't have a better idea. As David recommends, I'm a xemacs.deb refusenik, with either a dummy (unused in daily work) installation or even a virtual installation (ie, an empty package that provides the emacs virtual package to keep dpkg happy). 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. 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. 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.