"Davide G. M. Salvetti" <[EMAIL PROTECTED]> writes:
> 0) I think your's a good proposal
Thanks.
> 1) What about packages, like AUC TeX, which make no sense installing with
> XEmacs, since they are already included therein? Should they depend on
> emacsen or on the specific flavor(s) they need?
Yes. If a package really only works for a particular subset of
emacsen, then it should depend on those using "Depends: emacs19,
emacs20" or whatever.
> Or will we assume the user knows what she's doing and let her install a
> package she won't use, 'cause its only useful with an Emacs flavor she
> doesn't have?
Nah, no point. The dependency mechanism's partially there to let you
know when you're trying to install something useless.
> I think auctex (and similar packages) should depend on emacs{19,20}:
> maybe it's worth making this more explicit in your proposal.
I'll see about adding that.
> 2) How will we address run-time auto generated [1] el{,c} files? I
> decided to put auctex's ones in /var/lib/emacs/auctex; is it acceptable?
> (We couldn't certainly put them under /usr, like auctex did in the past.)
That's up to you. The scheme I proposed means that you have a lot of
flexibility about how you deal with installation issues, but here's an
example of how you might handle it. This example assumes that you
only need to byte compile some files -- that you don't need to perform
a more complex make process, though that wouldn't be hard to handle
either.
First you need to create two files (this is a slight modification from
my previous proposal -- there's no longer a provision for a set of
packages/<emacs>/{install,remove} scripts, there's only one script for
each action, but it may be called multiple times. The first arguement
lets you know what's going on.) The scripts are as follows:
/usr/lib/emacsen-common/packages/install/auctex
/usr/lib/emacsen-common/packages/remove/auctex
Whenever an emacsen is installed, the install script will be called
once with the first arguement set to the flavor being installed, and
the rest of the arguments set to the flavors already installed, and
then called once again with the first argument set to the generic
flavor "emacs", and the rest of the arguements set the flavors already
installed.
When the auctex package is first installed, the install/auctex script
will be called once for every emacs flavor already installed and once
for the generic flavor "emacs" with the arguments the same as above.
Note that you can tell whether you're being called for an emacsen
install or update by looking to see if the first argument appears
again in the rest of the arguments.
Here's an example of what you might put into the install/auctex script
if you only had a few things to byte compile (you may want to leave
off the "echo's"):
[ This particular script hasn't been tested, so be careful. ]
#!/bin/sh
set -e
FLAVOR=$1
echo install/auctex: Handling install of emacsen flavor ${FLAVOR}
byte_compile_options="-batch -f batch-byte-compile"
el_files=<your list here>
el_dir=/usr/share/emacs/site-lisp/auctex/
elc_dir=/usr/share/${FLAVOR}/site-lisp/auctex/
el_path_list=`echo ${auctex_el_files} | perl -pe 's|^|${el_dir}|o'`
elc_path_list=`echo ${auctex_el_files} | perl -pe 's|^|${elc_dir}|o'`
if [ ${FLAVOR} != emacs ]
then
echo install/auctex: byte-compiling for ${FLAVOR}
# If we had .el files that needed byte compiling in the package dir,
# this is how we'd handle it.
# Copy the temp .el files
cp ${el_path_list} ${elc_dir}
# Byte compile them
${FLAVOR} ${byte_compile_options} ${el_path_list}
# remove the redundant .el files
# presumes that any .el files in the <flavor> dir are trash.
rm ${elc_dir}/*.el
fi
exit 0;
And here's what you might put into the remove/auctex script:
[ This particular script hasn't been tested either, so be careful. ]
#!/bin/sh
set -e
FLAVOR=$1
echo remove/auctex: Handling removal of emacsen flavor ${FLAVOR}
if [ ${FLAVOR} != emacs ]
then
echo emacsen-common: purging byte-compiled files for ${FLAVOR}
rm -f /usr/share/${FLAVOR}/site-lisp/*.elc
fi
exit 0;
Does that make sense? I know this infrastructure all works since the
emacsen-common package (which provides this mechanism) also depends on
it :>
> [1]: auctex needs to update (by cron.weekly) a bunch of elisp files
> automatically generated from site installed TeX packages.
Wouldn't it be better to coordinate a script name with the TeX
maintainers and have them so something like
if [ -e /usr/lib/auctex/update-tex-elisp ]
then
/usr/lib/auctex/update-tex-elisp somedir
fi
in their postinst when $1 == 'upgrade' or $1 == 'install'?
Cron.weekly seems a waste. Sounds like an addition to policy would be
better.
> 3) A minor note: wouldn't be emacs-common a better name instead of
> emacsen-common?
Well, I thought it was sort of a toss up, and since we already had to
use emacsen as the virtual package name, emacsen-common seemed a
better match.
> 4) This one isn't directly related to your proposal, anyway, since we're
> going to update policy: could we add a note to emacs add-on package
> maintainers telling them to use (autoload ) forms rather than (load ) ones
> under /etc/<emacs>/site-start.d/? (Rationale: you don't want to
> automatically load something you may not use, especially in a site wide
> file.) [Currently debview has (load "deb-view") in
> /etc/emacs/site-start.d/50debview.el; should I file a bug report?]
That sounds like a good idea. Since I seem to be making the "big
emacs policy document" I'll stick it in as a recommendation.
> It isn't against FSSTND and I think we'll have to do it anyway, when we'll
> switch from FSSTND to FHS.
Consider the proposal changed. The new emacs 20 package (which works
as of today) puts all it's appropriate suff in /usr/share and
/usr/local/share. I'll update the proposal shortly.
Let me know if I can explain something further.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
