From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Debian's idiosyncratic complexification of Emacs [Was: Emacs vista build failures] Date: Tue, 15 Jul 2008 10:15:19 +0000 Message-ID: <20080715101519.GA2100@muc.de> 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1216116023 14810 80.91.229.12 (15 Jul 2008 10:00:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 15 Jul 2008 10:00:23 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 15 12:01:10 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 1KIhLC-0002i1-MW for ged-emacs-devel@m.gmane.org; Tue, 15 Jul 2008 12:01:03 +0200 Original-Received: from localhost ([127.0.0.1]:33625 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KIhKJ-00051y-TD for ged-emacs-devel@m.gmane.org; Tue, 15 Jul 2008 06:00:07 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KIhA7-0000OT-FQ for emacs-devel@gnu.org; Tue, 15 Jul 2008 05:49:35 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KIhA6-0000O6-Ui for emacs-devel@gnu.org; Tue, 15 Jul 2008 05:49:35 -0400 Original-Received: from [199.232.76.173] (port=45576 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KIhA6-0000O1-2k for emacs-devel@gnu.org; Tue, 15 Jul 2008 05:49:34 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:2978 helo=mail.muc.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KIhA5-00045K-Gn for emacs-devel@gnu.org; Tue, 15 Jul 2008 05:49:33 -0400 Original-Received: (qmail 43820 invoked by uid 3782); 15 Jul 2008 09:49:30 -0000 Original-Received: from acm.muc.de (pD9E50F71.dip.t-dialin.net [217.229.15.113]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Tue, 15 Jul 2008 11:49:28 +0200 Original-Received: (qmail 3349 invoked by uid 1000); 15 Jul 2008 10:15:19 -0000 Content-Disposition: inline In-Reply-To: <20080715013845.GX3675@rzlab.ucr.edu> User-Agent: Mutt/1.5.9i X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) X-Primary-Address: acm@muc.de X-detected-kernel: by monty-python.gnu.org: FreeBSD 4.6-4.9 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:100731 Archived-At: '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. > And no, it's not me. :-) > > Tell me, why is it considered helpful to include a content-free > > site-start.el? > We don't include a content-free site-start.el; here is its content: > ;; Emacsen independent startup file. All of the various installed > ;; flavors of emacs (emacs 19, emacs 20, xemacs) will load this file > ;; at startup. Make sure any code you put here is emacs flavor > ;; independent. > ;; Package maintainers: do not have Debian packages edit this file. > ;; See the policy manual for the proper way to handle Emacs package > ;; initialization code. Er, I said "content-free", not "comment-free". 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. > > The only thing this does is to prevent the loading of the > > site-start.el in the standard Emacs place, i.e. > > /usr/local/share/emacs/site-lisp/ (This is documented on page "Init > > File" of the Emacs manual.) > Configuration files such as site-start.el need to be in /etc by FHS, > and by Debian policy. 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. 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 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/..... > > I do not see the purpose of this extra layer of complexity that > > Debian has wrapped around (X)Emacs. > The purpose is to make it possible for packages to work on specific > versions of emacs, all versions of emacs, for users to modify the > files and have their changes automatically respected, and to allow for > add-on packages to be easily installed and automatically configured to > work site-wide without the need for users to modify their own .emacs > files or do anything else to deal with it. OK, thanks! > 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. > .... and frankly aren't something that upstreams spend much time > contemplating. You're not wrong there! > Don Armstrong -- Alan Mackenzie (Nuremberg, Germany).