[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Debian's idiosyncratic complexification of Emacs
From: |
Manoj Srivastava |
Subject: |
Re: Debian's idiosyncratic complexification of Emacs |
Date: |
Wed, 16 Jul 2008 09:09:31 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) (x86_64-unknown-linux-gnu) |
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
- Re: Debian's idiosyncratic complexification of Emacs, (continued)
- Re: Debian's idiosyncratic complexification of Emacs [Was: Emacs vista build failures], Don Armstrong, 2008/07/14
- Re: Debian's idiosyncratic complexification of Emacs, Stefan Monnier, 2008/07/14
- Re: Debian's idiosyncratic complexification of Emacs, Don Armstrong, 2008/07/15
- Re: Debian's idiosyncratic complexification of Emacs [Was: Emacs vista build failures], Stephen J. Turnbull, 2008/07/15
- Re: Debian's idiosyncratic complexification of Emacs [Was: Emacs vista build failures], Alan Mackenzie, 2008/07/15
- Re: Debian's idiosyncratic complexification of Emacs, David Kastrup, 2008/07/15
- Re: Debian's idiosyncratic complexification of Emacs,
Manoj Srivastava <=
- Re: Debian's idiosyncratic complexification of Emacs, Stefan Monnier, 2008/07/16
- Re: Debian's idiosyncratic complexification of Emacs, Karl Fogel, 2008/07/16
- Re: Debian's idiosyncratic complexification of Emacs, Karl Fogel, 2008/07/16
- Re: Debian's idiosyncratic complexification of Emacs, Manoj Srivastava, 2008/07/16
- Re: Debian's idiosyncratic complexification of Emacs, Karl Fogel, 2008/07/21
- Re: Debian's idiosyncratic complexification of Emacs, Miles Bader, 2008/07/22
- Re: Debian's idiosyncratic complexification of Emacs, Manoj Srivastava, 2008/07/22
- Re: Debian's idiosyncratic complexification of Emacs, Michael Olson, 2008/07/23
- Re: Debian's idiosyncratic complexification of Emacs, Stefan Monnier, 2008/07/23
- Re: Debian's idiosyncratic complexification of Emacs, Manoj Srivastava, 2008/07/24