Re: Proposal: emacsen and add-on package handling
I answer on debian-devel, since this is not a policy discussion.
>>>>> "MS" == Manoj Srivastava.
MS> 1) /usr/lib/<emacs>/packages/emacsen-install/vm
MS> /usr/lib/<emacs>/packages/emacsen-remove/vm
MS> So, since <macs> = emacs,xemacs20,emacs19,emacs20, this means 8 files?
No, that should be "/usr/lib/emacsen-common/packages/{install,remove}/vm",
i.e. 2 files. (Also note there is no "emacsen-" before {install,remove}).
MS> What do the files do? Do they compile the .el files? Do they
MS> move/remove elc files?
They compile ".el" files and put them in the appropriate directories,
depending on the arguments they are called with.
Robert> Don't forget that the argument list to the add-on package install
Robert> scripts will indicate both the flavor being installed, and the
Robert> flavors already installed. In this case, since we're actually
Robert> installing a flavor, the first argument won't appear in the
Robert> subsequent arguments.
MS> I'm very confused.
Rob means the first time you install an emacsen flavor it won't be
present in the installed flavors list. The first argument is the flavor
being installed, while the subsequent ones are the flavors already
installed.
But I think few add on packages actually need to parse the list of
installed flavors: they'll probably need to look just at the first
argument, as they are called one time for every flavor already installed
(or being installed) with that flavor as the first argument. (Actually,
they are called one more time with the special flavor "emacs" as argument
upon their selves installation, to let them do flavor independent sort of
things.)
I'll show you some examples later, to clarify this the best I can.
Robert> C) Each add-on package has the right to place files into the
Robert> following directories:
Robert> /etc/<emacs>/site-start.d
Robert> /usr/lib/<emacs>/site-lisp/<package-name>
^^^
This it a typo: you should read it:
"/usr/share/<emacs>/site-lisp/<package-name>".
We decide to switch to "/usr/share" for our architectural independent
elisp files, considering it isn't against FSSTND and would be mandated by
FHS when we'll decide to switch.
MS> So, four sets of directories? Does that mean emacs contains the el
MS> files, and x?emacs{19,20} have the elc files?
Probably among etc's `/etc/emacs/site-start.d/' should be the one to be
used by the vast majority of add on packages, as the others are flavor
specific, and you usually don't want to put byte compiled files in /etc,
while you could track which emacs flavor is running evaluating
debian-flavor, therefore being able to use just one file in
"/etc/site-start.d/" to handle all flavors (just in case you need to
behave differently for some of them).
With respect to "/usr/share/<emacs>/site-lisp/<package-name>/" my
understanding is to let "<emacs> = emacs" for elisp source and "<emacs> =
debian-flavor" for byte compiled files.
Robert> 6) Mandatory binary symlink
Robert>
Robert> Each emacsen main package will have a symlink
Robert> /usr/bin/<package-name> to /usr/bin/<emacs-binary> so that when
Robert> add-on package install/remove scripts are called, they can just
Robert> use /usr/bin/$ARGV[0] to get the right binary for
Robert> byte-compilation.
MS> Umm, what is a main package in this context? /usr/bin/vm? That can't
MS> be right. Does this apply to me at all? or you mean xemacs20 should
MS> point to xemacs-20.3?
No. Rob actually means you can use "$ARGV[1]", aka "$1" in shell script,
to get the right binary for byte-compilation.
MS> When are the elc files generated?
At add-on package install time and at new-emacsen-flavor package install
time, i.e. when your scripts in "/.../packages/{install,remove}" are
called.
MS> Do I have to have all the flavours installed on my box, and
MS> pregenerate the elc files?
I won't recommend this option, especially for large packages like vm: the
user won't probably have all flavors installed, so it would be a disk
space waste.
I'll try to make it clearer with some real code, from mailcrypt. Note
that mailcrypt depends on emacs19|emacs20, as it ships by default in
Xemacs, so I ignore xemacs19|xemacs20 and the dummy flavor emacs.
1) "/usr/lib/emacsen-common/packages/install/mailcrypt":
>-------------------------------------------------------------------------<
#!/bin/bash -e
#
# elisp install file for Debian mailcrypt package.
# $Id: emacsen.install,v 1.13 1998/02/24 16:07:14 salve Exp $
#
# Copyright © Davide G. M. Salvetti <salve@debian.org>, 1998.
# --- cut non relevant part: copyright ---
PACKAGE=mailcrypt
FLAVOR=$1
ELDIR=/usr/share/emacs/site-lisp/$PACKAGE/
ELCDIR=/usr/share/$FLAVOR/site-lisp/$PACKAGE/
#-=-
SOURCES="mailcrypt.el mc-toplev.el mc-pgp.el mc-remail.el"
EFLAGS="-batch -q -l load-path-hack.el -f batch-byte-compile"
#-=-
case "$FLAVOR" in
emacs19|emacs20)
echo -n "install/$PACKAGE: Byte-compiling for $FLAVOR..."
install -m 755 -d $ELCDIR
for i in $SOURCES; do cp $ELDIR/$i $ELCDIR; done
cat <<-EOF >$ELCDIR/load-path-hack.el
(setq load-path (cons nil load-path))
EOF
(cd $ELCDIR && $FLAVOR $EFLAGS $SOURCES 2>/dev/null)
rm $ELCDIR/*.el
echo " done."
;;
*)
echo "install/$PACKAGE: Ignoring emacsen flavor $FLAVOR."
;;
esac
exit 0
# --- cut non relevant part: local variables ---
>-------------------------------------------------------------------------<
(Note the hack to add the current directory to "load-path": do you know
some cleaner way to do it?)
You can see I call the $FLAVOR binary to byte-compile. (Mailcrypt package
ships "$SOURCES" in "$ELDIR").
2) "/usr/lib/emacsen-common/packages/remove/mailcrypt":
>-------------------------------------------------------------------------<
#!/bin/bash -e
#
# elisp remove file for Debian mailcrypt package.
# $Id: emacsen.remove,v 1.9 1998/02/24 16:08:32 salve Exp $
#
# Copyright © Davide G. M. Salvetti <salve@debian.org>, 1998.
# --- cut non relevant part: copyright ---
PACKAGE=mailcrypt
FLAVOR=$1
ELCDIR=/usr/share/$FLAVOR/site-lisp/$PACKAGE/
case "$FLAVOR" in
emacs19|emacs20)
echo -n "remove/$PACKAGE: Removing for $FLAVOR..."
rm -f $ELCDIR/*.elc
echo " done."
;;
*)
echo "remove/$PACKAGE: Ignoring emacsen flavor $FLAVOR."
;;
esac
exit 0
# --- cut non relevant part: local variables ---
>-------------------------------------------------------------------------<
Every package should add the proper (flavor dependent) directory to
"load-path": I choose to do it in:
3) "/usr/share/emacs/site-lisp/mailcrypt-init.el":
>-------------------------------------------------------------------------<
;-*-emacs-lisp-*-
;; mailcrypt-init.el, perform mailcrypt initialization
;; Copyright (C) 1996 Joe Reinhardt <joe-reinhardt@uiowa.edu>
;; Copyright © Davide G. M. Salvetti <salve@debian.org>, 1998.
;; --- cut non relevant part: copyright ---
(provide 'mailcrypt-init)
;; --- cut non relevant part: autoloads ---
;; load path
(setq load-path (cons (concat "/usr/share/"
(symbol-name debian-emacs-flavor)
"/site-lisp/mailcrypt") load-path))
;;;end
>-------------------------------------------------------------------------<
This is in "/usr/share/emacs/site-lisp/" 'cause that's a place included by
default in "load-path".
Doing this way it's not loaded by default, as it would be if I had put it
in "/etc/emacs/site-start.d/", which is exactly what I want: users wanting
it should put "(require mailcrypt-init)" in their "~/.emacs", while
sysadmins could put it in "/ect/emacs/site-start.el" if they want to. (I
do this way 'cause mailcrypt autoloads on normal mail functions changing
their behavior, something that could confuse non-mailcrypt-aware users;
you may want something different for less intrusive packages.)
I call: "/usr/lib/emacsen-common/emacs-package-install $PACKAGE" in the
postinst and "/usr/lib/emacsen-common/emacs-package-remove $PACKAGE" in
the prerm.
Sorry for the long post, I hope it helps someone.
--
Davide G. M. Salvetti
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: