Re: Debian's idiosyncratic complexification of Emacs

[Manoj Srivastava]

On Thu, 17 Jul 2008 05:42:11 +0900, Stephen J Turnbull <address@hidden> said: 

> Manoj Srivastava writes:
>> On Tue, 15 Jul 2008 08:50:21 +0200, David Kastrup <address@hidden> 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.

        Pardon me, I do think I know the problem that Debian was trying
 to solve when they implemented this mechanism. Yes, it does break the
 expectation that the .el and .elc files live in the same location; I'll
 see what can be done to correct that, while still addressing the
 problem that does need to be solved for Debian users (by adding
 symlinks as David noited is the right thing to do).

> 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.

        Actually, I just add whole subdir trees (for a site-wide
 install) in /usr/local/share/emacs/site-lisp or add to the loadpath in
 .emacs (for a personal installation); which is slightly different than
 keeping all the code in .emacs.

> 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.

        Right. Nothing will ever edit or modify anything you put in
 /etc/emacs/site-start.el. 

> 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.

        Sure. I am just puzzled as to why I am not experiencing _any_ of
 these issues. If I could reproduce some of the issues, perhaps I can do
 my bit to solve the problem for other folks too.

        manoj
-- 
Virtue is a relative term. Spock, "Friday's Child", stardate 3499.1
Manoj Srivastava <address@hidden> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C