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 09:09:31 -0500 Organization: Manoj Srivastava's Home Message-ID: <87mykhkjj8.fsf@anzu.internal.golden-gryphon.com> References: <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> <20080715013845.GX3675@rzlab.ucr.edu> <20080715101519.GA2100@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1216217431 20831 80.91.229.12 (16 Jul 2008 14:10:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 16 Jul 2008 14:10:31 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 16 16:11:18 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 1KJ7iu-0006wc-7m for ged-emacs-devel@m.gmane.org; Wed, 16 Jul 2008 16:11:17 +0200 Original-Received: from localhost ([127.0.0.1]:51240 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KJ7i1-0006pw-O5 for ged-emacs-devel@m.gmane.org; Wed, 16 Jul 2008 10:10:21 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KJ7hl-0005wX-Tw for emacs-devel@gnu.org; Wed, 16 Jul 2008 10:10:05 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KJ7hk-0005tM-SJ for emacs-devel@gnu.org; Wed, 16 Jul 2008 10:10:05 -0400 Original-Received: from [199.232.76.173] (port=50804 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KJ7hk-0005rX-Jp for emacs-devel@gnu.org; Wed, 16 Jul 2008 10:10:04 -0400 Original-Received: from main.gmane.org ([80.91.229.2]:42330 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 1KJ7hj-0003ve-RW for emacs-devel@gnu.org; Wed, 16 Jul 2008 10:10:04 -0400 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KJ7hY-0002RA-NG for emacs-devel@gnu.org; Wed, 16 Jul 2008 14:09:52 +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 14:09:52 +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 14:09:52 +0000 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 101 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:WDoFKbyCMFG/2eDFqEhtYqe9mp4= 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:100809 Archived-At: On Tue, 15 Jul 2008 10:15:19 +0000, Alan Mackenzie said: > 'Morning, Don! > On Mon, Jul 14, 2008 at 06:38:45PM -0700, Don Armstrong wrote: >> On Mon, 14 Jul 2008, Alan Mackenzie wrote: >> > Those ~2 hours of my life are permanently lost, they're gone for >> > ever, I'll never get them back again. >> Perhaps I'm being elitist, but it took me all of 5 minutes to look up >> the documentation for this, and rework through how this all was done. > Will you please get the point. It isn't the time it takes to "look up > documentation", or the 35.72 seconds it takes to edit an elisp startup > file. It's the two hours it takes from realising "something's not > working here", going through checking things like pertinent disk > partitions are mounted, there's no symbolic links fouling things up. > Maybe I'm hopelessly old-fashioned here, but when I see something not > working, I usually assume it's my fault, first. > If this sort of thing happened on every Debian package, and you > install, say, 100 packages at installation, this would add an extra > 200 hours to the installation process. Well, on a Debian system, the norm is to expect to be able to edit any configuration file under /etc. So, I would start looking into /etc for any Debian package -- even emacs (my /usr is mounted read-only, and often the /usr/share is actually shared). >> > Tell me, why is it considered helpful to include a content-free >> > site-start.el? A placeholder to let users know there is something to edit, and where it is (you can look at the dpkg -L output, and grep for site-start.el > Even so, there is a bug here. "the policy manual" should be > identified, otherwise another two hours will be wasted by each person > who tracks it down, or more likely, who attempts to track it down. I think the Debian technical policy manual hint is for package maintainers; they had bloody well better know what the policy manual is and what it contains. >> Configuration files such as site-start.el need to be in /etc by FHS, >> and by Debian policy. >> scream of rage> site-start.el typically goes in > /usr/local/share/emacs/site-lisp, according to the Emacs > documentation. So there is a conflict here between an upstream > package's recommendations and Debian's policies. OK, it's not as bad > as for qmail, but it exists. I've got a lot of sympathy for qmail's > author (Dan Bernstein)'s insistence that qmail's files went into > _exactly_ the same location in any installation. Well, I am afraid that systems integration means that sometimes you have to change upstream conventions in order for the software to integrate better into the distribution; though I believe a symbolic link in $PREFIX/share/emacs/site-lisp is not a bad idea. > You seem to be taking the view that it's OK for Debian to completely > supersede upstream policies - you use the wording "need to be" rather > than the more accurate "ought to be". I think that is an accurate description of Debian's stance on systems integration. > I don't think this is OK at all. It causes the waste of lots of lots > of people's time. I think Debian has an onus to try and conform to > upstream package policies AS WELL AS its own. For Emacs a solution is > clear: put /etc/... lower in load-path than /usr/local/share/..... As far as possible, sure. But when there is a direct conflict, the only sane way top resolve this for _all_ packages is to have a technical policy that is actually observed, all the time, and not just haphazardly. >> There may be better implementations of that complexity, but the >> features that it gives are necessary, .... > I'm trying to picture where this might be useful. Typically, an Emacs > user on his home box is going to have exactly one version of (X)Emacs > installed, so the complexity will be a burden. An Emacs hacker, such > as all of us, is going to have several, or even many, (X)Emacs > versions hanging around, in his own custom built directory structure, > and will probably have built these from source. I can't see Debian's > complexity being useful for either of these (though I may be wrong). > A sysadmin administering a mutil-hacker development shop would surely > find it useful. But we also try to catrer to people who are on multi-user systems, and thus have different needs; my work machines have multiple editors available (couple of emacsen, eclipse, all kinds of vi-clones), since different people might use them, and I often have several emacs versions installed, in order to test of the few emacs add ons I still maintain. manoj -- Lost interest? It's so bad I've lost apathy. Manoj Srivastava 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C