From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Bob Proulx Newsgroups: gmane.emacs.help Subject: Re: best gnu/linux distro for emacs Date: Sun, 24 Mar 2013 14:37:10 -0600 Message-ID: <20130324203710.GA5733@hysteria.proulx.com> References: <87y5dep0al.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1364157449 25041 80.91.229.3 (24 Mar 2013 20:37:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 24 Mar 2013 20:37:29 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun Mar 24 21:37:55 2013 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UJrfs-00080r-MY for geh-help-gnu-emacs@m.gmane.org; Sun, 24 Mar 2013 21:37:52 +0100 Original-Received: from localhost ([::1]:34052 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJrfV-0008C7-26 for geh-help-gnu-emacs@m.gmane.org; Sun, 24 Mar 2013 16:37:29 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:59924) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJrfG-0008Bv-Cs for help-gnu-emacs@gnu.org; Sun, 24 Mar 2013 16:37:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UJrfF-00071q-31 for help-gnu-emacs@gnu.org; Sun, 24 Mar 2013 16:37:14 -0400 Original-Received: from joseki.proulx.com ([216.17.153.58]:34023) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJrfE-00071h-Mz for help-gnu-emacs@gnu.org; Sun, 24 Mar 2013 16:37:13 -0400 Original-Received: from hysteria.proulx.com (hysteria.proulx.com [192.168.230.119]) by joseki.proulx.com (Postfix) with ESMTP id 61C7B211DA for ; Sun, 24 Mar 2013 14:37:11 -0600 (MDT) Original-Received: by hysteria.proulx.com (Postfix, from userid 1000) id 257672DCDF; Sun, 24 Mar 2013 14:37:10 -0600 (MDT) Mail-Followup-To: help-gnu-emacs@gnu.org Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 216.17.153.58 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:89725 Archived-At: Alan Mackenzie wrote: > Bob Proulx wrote: > > What makes /usr/local/share/emacs/site-lisp/site-start.el the normal > > path and /etc/emacs/site-start.el something not normal? > > A very good question! I've had a quick search of the Emacs manual and not > found anything specifying the contents of load-path. The next best thing > was: > > "Many sites put these files in a subdirectory named `site-lisp' in the > Emacs installation directory, such as `/usr/local/share/emacs/site-lisp'." > > , from the chapter "The Emacs Initialization File". I'm confident that > /etc/emacs exists nowhere in the manual. I am a big believer in doing things the way it is documented. But in this case I am going to argue that the documentation was insufficient to the task. Because I think this is simply a case of the documentation not sufficiently describing how emacs might be compiled and installed. Basically all of the stuff that we normally see in the 'configure' script set of options. Things get messy where theory meets practice and I can see the documentation trying to avoid getting into that mess. But here it has caused a problem. > When I start emacs -Q, load-path contains the directories under > /usr/local/share/emacs/24.3/lisp together with > /usr/local/share/emacs/site-lisp. So it would seem, for a standard build, > that .../site-lisp is the only safe place for site-start.el. You say "for a standard build" and I think that needs more clarification. What is a standard build? Let me jump ahead and assume this was your own compilation and that you did not supply any configure options at all. (Since I think that is likely the case here.) Then for you the "standard build" really meant a local compilation and installation using all of the default configure options. Is that correct? > > In any case... One could always put the customizations in that file. > > That is rather what is expected. Or one could add a load statement > > there to load /usr/local/share/emacs/site-lisp/site-start.el if you > > want to keep the customizations there. It is six of one or a half > > dozen of the other. > > GRRR!!! Yes, one can do any of these things, but only after having > discovered there's a problem which needs fixing, and diagnosing that > problem. This cost me, perhaps, an hour or two back in 2005 when I > first installed Debian on a new PC, and my site-start.el wasn't loading. This is really uncovering a deeper layer of philosophical question. The question is how do you package software for distribution to a wide audience of people? Where do you put it? How do you do this while allowing people to compile and install their own software? This is the question that must be answered in order to address your issue. A local compilation using the standard autotools and no configure options will root all of the paths in the /usr/local tree. Programs will go in /usr/local/bin and so forth. If that is the standard build then should a software distribution (pick any) compile their software using the same configure without any options and install in /usr/local and so be a "standard build"? [No. Please no.] Instead we have a separation with system packaged paths in / and local user compiled paths in /usr/local. We hold /usr/local inviolate against system intrusion. And the reverse is almost the same. We don't expect that if we compile and install to /usr/local that it will smash over system package managed files in /. Knowing this then if I am using a locally compiled program installed in /usr/local/bin and want to modify its configuration then I expect it to be configured in /usr/local somewhere usually /usr/local/etc but sometimes elsewhere. If I am using a system package installed program in /bin (or /usr/bin) then I expect it to be configured somewhere in / usually /etc but sometimes elsewhere too but definitely not /usr/local. Bob