Subject: Emacs per-package startup files

From: Ian Jackson <[email-masked]>
Date: Mon, 5 Aug 96 14:05 BST

OK, so we've decided to have packages put their Emacs startup stuff in
a directory, with one file per package.

The directory obviously ought to go in /etc, and the files made
conffiles, so that the sysadmin can reconfigure things.

/etc/emacs/site-start.d ?

Ian.

---

From: [email-masked] (Erick Branderhorst)
Date: Mon, 5 Aug 1996 15:48:09 +0100

> /etc/emacs/site-start.d ?

Please wait a minute.

How will these files be read.  In alphabetical or fileposition order?
Some scripts written in these might work only properly if some other
script is executed first.  I can't come up with some proper example 
but I can imagine that this might be very true.  This will force us
to scan the files several times and execute what is in there only if
some specific other scripts are executed earlier.

Sorry not native english speaker, so the above might be too cryptic,
but I see some problem here.  We might be better of with some script
modifying a file like install-info does and have some order where 
scripts can be put in that file (top, middle, bottom, or 0..9).

Erick

---

From: Yves Arrouye <[email-masked]>
Date: Tue, 6 Aug 1996 00:22:08 +0200

> some specific other scripts are executed earlier.

If the files there really depend on each other, then it may be nice
to require that each xxxx.el file contains

	(provide 'site-start-xxx)

(as the *last* line so nothing is provided in case of error), and other
files will just use

	(require 'site-start-xxx)

as needed.

Or is there a reason not to do that?
Yves.

---

From: [email-masked] (Erick Branderhorst)
Date: Tue, 6 Aug 1996 10:12:32 +0100

> 	(require 'site-start-xxx)

Nice of course but now it happens that package A require stuff from B to be
loaded, but this code for A is always executed before the stuff from B is
executed and so A fails unless, the load process is run again and checks are
made whether something needs to be loaded or if it has been loaded in an
earlier run.

Erick

---

From: Rob Browning <[email-masked]>
Date: 06 Aug 1996 10:29:45 -0500

> made whether something needs to be loaded or if it has been loaded in an

Is it actually going to be that hard to just avoid situations that
require this?

--
Rob

---

From: Yves Arrouye <[email-masked]>
Date: Tue, 6 Aug 1996 23:24:20 +0200

> made whether something needs to be loaded or if it has been loaded in an

That's wrong. If A requires stuff from B we'll have something like:

  ; package a

  (require 'site-start-b)

  ; do things here...

  (provide 'site-start-a)

and

  ; package b

  ; do things here...

  (provide 'site-start-b)

Now whatever the order packages are loaded, it works. If we load a, we
get

   - a starts interpreting
   - a requires b
     -> b starts interpreting
     -> b ends providing site-start-b, so a's require is fullfilled
   - a continues interpreting
   - a ends providing site-start-a

and if b was already loaded b is not loaded again.

The only problem would be with circular dependencies, but then nothing
can help you in such cases...

Yves.

P.S.: Erick, I read the list. No need to send emails twice.

---

From: [email-masked] (Emilio Lopes)
Date: Tue, 6 Aug 96 20:13 EST

>>>>> "IJ" == Ian Jackson <[email-masked]> wrote:

IJ> /etc/emacs/site-start.d ?

There would be something else inside /etc/emacs or just site-start.d?
If not, it seems we need a better name.

/etc/site-start.d?
/etc/emacs.d?
/etc/emacs-start.d?
/etc/emacs-lisp.d?

Yes, I know would nice to have something that looks like
site-start.el.

Ciao, Emilio.

-- 
                 Emilio C. Lopes <mailto:[email-masked]>
               Instituto de Fisica da Universidade de Sao Paulo
             Caixa Postal 66318, 05389-970 Sao Paulo - SP, BRAZIL
              Phone: (+55) (11) 818-6724 (Voice) / 818-6715 (Fax)

---

From: [email-masked] (Emilio Lopes)
Date: Tue, 6 Aug 96 20:51 EST

>>>>> "EB" == Erick Branderhorst <[email-masked]> wrote:

EB> How will these files be read.  In alphabetical or fileposition order?
EB> Some scripts written in these might work only properly if some other
EB> script is executed first.  I can't come up with some proper example 
EB> but I can imagine that this might be very true.  This will force us
EB> to scan the files several times and execute what is in there only if
EB> some specific other scripts are executed earlier.

Maybe they could be eval'ed following some number scheme, a la init.

Ciao, Emilio.

---

From: [email-masked] (Emilio Lopes)
Date: Tue, 6 Aug 96 20:51 EST

Ciao, Emilio.

---

From: [email-masked]
Date: 08 Aug 1996 01:11:35 -0400

Umm, /usr/lib/emacs/site-lisp/ is already there, and already the right
place for this sort of thing. Next question?

As for ordering: use require, and then safe-append a section to
/etc/site-start.el, JUST LIKE EVERYTHING ALREADY DOES... we don't need
a new mechanism here, just some common simple automation of the one
that vm, w3, gnats, and others already use...

			_Mark_ <[email-masked]>
			The Herd of Kittens
			Debian emacs package maintainer

---

From: Ian Jackson <[email-masked]>
Date: Fri, 9 Aug 96 21:39 BST

> place for this sort of thing. Next question?

Err, I don't think so.  Files in /usr/lib/emacs/site-lisp aren't
loaded automatically (and shouldn't be).

> that vm, w3, gnats, and others already use...

Respectfully, I disagree.

Experience with /usr/info/dir, inetd.conf, and indeed with
site-start.el (/etc/site-start.el vs. site-lisp/site-start.el and
symlinks, &c) has taught us, I feel, that it is a bad thing to have
many different packages all dynamically update the same file just to
add and remove their own little bits from it.

Contrast this with /etc/rc?.d and /etc/rc.boot, where there has been
little unfortunate interaction.

There's the question of how to distinguish changes made to the shared
file by the sysadmin from those made by package maintainer scripts.
This is much easier if each package's bit is in a separate file -
dpkg's conffiles mechanism can take care of it.

There's also the question of having a standard tool.  Obviously it
would be good to have a standard tool for this kind of thing (a la
install-mime and the rest).  However, the more you do this the more
of these little install-foo scripts you have, and the more stuff you
drag in when you try to install the package.  For example, supposing
Emacs were to provide a script to add things automatically I couldn't
use it, because dpkg can't depend on Emacs.  The script would have to
end up in dpkg itself.

So, all in all, I think it would be better to have an arrangement
where all the bits that packages would want to put in the site-start
are installed as conffiles in a directory, and arrange that the real
site-start runs every file in the directory a la run-parts.

As for ordering: the entries in site-start aren't supposed to require
much ordering.  After all, they're autoload definitions and the like.
I think a sequence numbering scheme like that for the other
package-put-a-file-in-here directories would be quite adequate.

Now Emacs is your (Mark Eichin's) package, so you get to decide how
things are to be done.  I still hope though that I (and others who may
agree with me) can persuade you that these arguments have merit, and
that it would be better and simpler in the long run if we started
making this not particularly arduous transition.

Either way I'd appreciate it if, when this discussion is concluded,
you could send me some text for the new policy manual about how elisp
should be managed.

Thanks,
Ian.

---

From: Mark Eichin <[email-masked]>
Date: 09 Aug 1996 23:26:21 -0400

first, thanks for clearing up a lot of the arguments. This is the
first message I've seen that actually gives a justification for doing
something new and different...

re dynamically updating the same file -- I guess that does make sense,
and the lack of mechanism for /etc/services and inetd.conf has
actually caused me trouble recently.  (I'd take that as an argument
for *more* micromanagement scripts [it would make it easier to fix the
/etc/passwd problem that mhpower mentioned], but in those cases we
can't really change the "database" because of existing use, whereas
with emacs we are free to do that.)

You're right, rc.boot has worked pretty well. (I'm a little less
sanguine about rc?.d, but they *seem* to do the right thing...)

Hmm. As for dpkg needing install-elisp, I'm not quite sure I buy that,
because it would seem to argue that *any* install-* should be included
in dpkg. Then again, there is only install-info which *is* in dpkg,
and install-mime which is in mime-support which has it's own
justification. There aren't any others...

Hmm. Dpkg already does a good job with creating needed directories, as
well... so it would really be sufficient for any package to drop in an
emacs mode without actually having emacs installed yet. Interesting.

I guess the only thing unresolved is what directory to use, and what
the little bit of elisp should look like that scans the directory.
I'll look at the text explaining rc.d numbering to see what makes
sense for that. (I guess in theory we need the ordering, but in
practice, with autoload, do we need ordering here at all? certainly
none of the existing packages need it. But I suppose picking an order
at least makes debugging easier...)

So, do these files go in /var/lib/emacs, /etc/emacs, or
/usr/lib/emacs/site-lisp, and why?  I can set it up and send changes
to the emacs package maintainers this weekend if that gets worked
out...

---

From: Ian Jackson <[email-masked]>
Date: Sat, 10 Aug 96 16:10 BST

Mark Eichin writes ("Re: Emacs per-package startup files"):
...
>  [it would make it easier to fix the

Right, that was my line of thought exactly.

...
> justification. There aren't any others...

If anyone writes others I'll be happy to include them in dpkg,
provided that they're GPL'd.

...
> to the emacs package maintainers this weekend if that gets worked

It needs to be in /etc, and the files must be conffiles, so that
sysadmins can edit them and so forth.

I suggested /etc/emacs/site-start.d because we already have one Emacs
/etc file and /etc is already full of stuff.

> the little bit of elisp should look like that scans the directory.

How about making /usr/lib/emacs/site-start.el a file rather than a
symlink, and having it load /etc/emacs/site-start.el and run
/etc/emacs/site-start.d.

> at least makes debugging easier...)

If you just sort the filenames before you run them you'll get the
ordering for free, and if we say that people who don't know what
number to use or don't think they have ordering constraints use 50
then if we do decide we want something loaded early we can do it.

Ian.

---

From: "Brian C. White" <[email-masked]>
Date: Sat, 10 Aug 1996 11:50:02 -0400

> justification. There aren't any others...

I agree that "install-elisp" should be the responsibility of emacs.
Packages that want to use it should put an

	if [ -x /sbin/install-elisp ]
	then
		[...]
	fi

around the install/uninstall code.  This will allow packages to take
advantage of it if available, but not actually depend on emacs being
installed.  This is the line I've taken with mime-support.

There is a disadvantage that installing emacs after installing a
package ("p") that tries to call "install-elisp" will mean that
"p" is completely unknown to emacs until "p" is either reinstalled
or upgraded.  I personally don't see this as a problem as upgrades
happen fairly regularly.

Of course, the above problem only exists if "install-elisp" does some
setup work, as "install-mime" does.

> to the emacs package maintainers this weekend if that gets worked

I'd vote for "/usr/lib/emacs/site-lisp".  Why?  Because "/var/lib/emacs"
is for files that can't be on a read-only filesystem and "/etc/emacs" is
for user config files and the like.

                                        Brian
                               ( [email-masked] )

-------------------------------------------------------------------------------
    In theory, theory and practice are the same.  In practice, they're not.

---

From: Ian Jackson <[email-masked]>
Date: Mon, 12 Aug 96 03:26 BST

Brian C. White writes ("Re: Emacs per-package startup files"):
...
> [someone:]

/usr/lib/emacs/site-lisp is for something entirely different.  It's
for the main lisp files (modes or whatever) that a package installs.

/var/lib is obviously wrong, as the files aren't changed in normal
operation.

The files need to be conffiles so that the sysadmin can modify their
behaviour, remove them, &c, and have their changes respected.  So it
needs to be in /etc.

Ian.