Re: Debian's idiosyncratic complexification of Emacs

[Manoj Srivastava]

On Tue, 15 Jul 2008 10:15:19 +0000, Alan Mackenzie <address@hidden> 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 <address@hidden> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C