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: Debian's idiosyncratic complexification of Emacs [Was: Emacs vista build failures] Date: Tue, 15 Jul 2008 08:54:50 +0900 Message-ID: <8763r858dx.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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1216078862 18122 80.91.229.12 (14 Jul 2008 23:41:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 14 Jul 2008 23:41:02 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 15 01:41:50 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 1KIXfn-0000Va-Re for ged-emacs-devel@m.gmane.org; Tue, 15 Jul 2008 01:41:40 +0200 Original-Received: from localhost ([127.0.0.1]:42048 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KIXev-0004Iz-OK for ged-emacs-devel@m.gmane.org; Mon, 14 Jul 2008 19:40:45 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KIXes-0004IT-8P for emacs-devel@gnu.org; Mon, 14 Jul 2008 19:40:42 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KIXer-0004IC-PT for emacs-devel@gnu.org; Mon, 14 Jul 2008 19:40:41 -0400 Original-Received: from [199.232.76.173] (port=48430 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KIXer-0004I2-I5 for emacs-devel@gnu.org; Mon, 14 Jul 2008 19:40:41 -0400 Original-Received: from mtps02.sk.tsukuba.ac.jp ([130.158.97.224]:49211) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KIXep-0006K2-Sa for emacs-devel@gnu.org; Mon, 14 Jul 2008 19:40:41 -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 028638003; Tue, 15 Jul 2008 08:40:37 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 7DB431A25C3; Tue, 15 Jul 2008 08:54:50 +0900 (JST) In-Reply-To: <20080714223059.GG3445@muc.de> 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:100704 Archived-At: > On Mon, Jul 14, 2008 at 01:42:42PM -0700, Don Armstrong wrote: > > David Kastrup wrote: > > > Forget about Debian and Emacs. They use a clever system for sharing > > > package code between different Emacs versions (which you can install > > > at the same time) and XEmacs, so clever that nobody understands it. > > > Lots of us understand it; it's pretty trivial. I beg to differ. The Debian Emacs Policy was a major PIMA for a couple of years. It may be simple to state by now, but its evolution was complex. The current state of peaceful coexistence required a number of tweaks. > > Thanks to that system, installing packaged emacs add-ons is > > absolutely trivial. Well, there are several other systems that make installing packaged Emacs add-ons absolutely trivial. Of course Debian would have a massive case of indigestion if you used them on a Debian-installed Emacsen, so they're kinda preempted. And historically, Debian installed add-ons caused a lot of annoyance to both upstream developers and users of Debianized Emacsen. Alan Mackenzie writes: > Tell me, why is it considered helpful to include a content-free > site-start.el? 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/ Don't you mean $prefix/share/emacs/site-lisp? IMHO, Debian should leave /usr/local pretty much entirely alone, maybe looking there late-ish in load-path or something. Site configs for Debian's Emacsen shouldn't be in /usr/local, though. For the Debian-distributed Emacs, prefix=/usr, and /usr/share/ needs to be reserved to Debian. OTOH, user settings kept in /etc/emacs/ will be carefully preserved by Debian tools. At one time it wasn't content-free, either. In particular, it loaded the initialization code for packaged Lisp. This meant that you could do --no-site-file in XEmacs (what's Emacs's idiom?) and do a packaged- Lisp-free bug report on core features. This is especially important if you've got monkey-patch libraries like APEL around. The easy thing to do is simply let Debian install an Emacs-to-keep- deb-deps-happy, and put your developer's Emacs (pl?) in /usr/local or /opt. Each Emacsen will then look in the standard place relative to its own $prefix (modulo Debian's redefinition of "standard"). > And even the maintainer of this document, debian-emacs-policy, admits > that it's not in an optimum state. It's not clear what the purpose of > `debian-startup' is (Emacs works well without it), or to whom Emacs must > indicate its flavour (er, flavor ;-), and what that achieves. Emacs v. XEmacs and Mule v. no-Mule introduce various bytecode incompatibilities. "Flavor" is used to point load-path at compiled Lisp that works for each variant. AFAIK that's explained in the Emacs Policy document, but it's been a while since I read it. The David and Don Show returns: > > > I know of _no_ upstream Emacs or XEmacs developer who claims to > > > understand or get along with the Debian setup. > > > There's no need for upstream developers to bother, since it's all > > handled for them by Debian Developers. Except for bug reports. Debian's XEmacs (unlike, say, Mandrivel's) is quite clean of core patches, so I don't recall ever needing to fire up a Debian XEmacs to diagnose a bug. (Of course, if it looks like a load-path issue, I always try to bounce it back to Debian, since it's their load-path, not ours. But even there --debug-paths (does Emacs have this switch?) usually wins if the user comes back to us.) And back to Alan: > Sorry, Don, you're just wrong here. It's _precisely_ the Debain > Developers' inclusion of the "blocking library" > (/etc/emacs<..>/site-start.el) which forces upstream developers > like me such bother. In the spirit of the GPL, Debian probably should have a notice on the splash screen that they've moved the standard startup files, and a link to an info node describing them. I'd not be surprised if it's already there but you just didn't notice it. > Why is it necessary to include these content-free files? Is there not > something that the Debian Emacs maintainer could do to resolve this > problem? How about changing the order of the directories in load-path, > for example? "See above", "not much", and "obviously they already do that, presumably with malice[sic] aforethought". N.B. I come not to praise the Debian Emacs Policy, but to give it its due: it's a reasonable compromise for the vast majority of users of Emacsen.