Re: Mailcrypt - EMACS package maintainers please read this message.
>>>>> "RB" == Rob Browning.
RB> Whenever an emacsen is installed, the install script will be
RB> called once with the first arguement set to the flavor being
RB> installed, and the rest of the arguments set to the flavors
RB> already installed, and then called once again with the first
RB> argument set to the generic flavor "emacs", and the rest of the
RB> arguements set the flavors already installed.
RB> When the auctex package is first installed, the install/auctex
RB> script will be called once for every emacs flavor already
RB> installed and once for the generic flavor "emacs" with the
RB> arguments the same as above. Note that you can tell whether
RB> you're being called for an emacsen install or update by looking
RB> to see if the first argument appears again in the rest of the
RB> arguments.
I'm not sure if I understand what the call with $1=emacs (generic flavor)
is for, in the case you are installing a new emacs package.
I think it may be useful for package who don't have to do flavor dependent
sort of things: it make sense to me to have this call when you install or
remove the add-on package itself. But I don't understand its purpose,
when you install or remove a specific version of emacs, considered it will
be called with that flavor as argument and the fact every add-on Depends
on at least some emacsen.
Can you clarify it, please?
RB> [ This particular script hasn't been tested, so be careful. ]
[...]
RB> # remove the redundant .el files # presumes that any .el files in
RB> the <flavor> dir are trash. rm ${elc_dir}/*.el fi exit 0;
This is a Bad assumption, IMHO: each package should only remove its own
files, even if other .el files in <flavor> dirs may be probably trash.
You can never tell for sure whether strange things are there for accident
or for a real purpose, if it's not you who put them there.
RB> And here's what you might put into the remove/auctex script:
RB> [ This particular script hasn't been tested either, so be
RB> careful. ]
[...]
RB> if [ ${FLAVOR} != emacs ] then echo emacsen-common: purging
RB> byte-compiled files for ${FLAVOR} rm -f
RB> /usr/share/${FLAVOR}/site-lisp/*.elc fi exit 0;
Ditto. Let each package just remove its own files, even if it's sure
${FLAVOR} is being removed.
If /usr/share/${FLAVOR} really is about to be removed, it should be
${FLAVOR} to remove orphaned files in there, after all add-ons have
removed their own.
>> [1]: auctex needs to update (by cron.weekly) a bunch of elisp
>> files automatically generated from site installed TeX packages.
RB> Wouldn't it be better to coordinate a script name with the TeX
RB> maintainers and have them so something like
RB> if [ -e /usr/lib/auctex/update-tex-elisp ] then
RB> /usr/lib/auctex/update-tex-elisp somedir fi
RB> in their postinst when $1 == 'upgrade' or $1 == 'install'?
RB> Cron.weekly seems a waste. Sounds like an addition to policy
RB> would be better.
There is an update-tex-elisp like script (named auctex-auto-load for
historical reasons), and it's indeed a good idea to let the TeX
maintainers be aware of it, but I think auctex still needs cron: it scans
/usr/local/lib/texmf/tex/ as well [1]. The sysadmin may want to install
things there (in fact I do it on my site) and there's no mean to assure he
will call auctex-auto-load after that. Comments?
[1]: Actually, the current release doesn't scan /usr/local, but this is a
(unreported) bug I already fixed: next releases will do it.
>> 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?]
RB> That sounds like a good idea. Since I seem to be making the "big
RB> emacs policy document" I'll stick it in as a recommendation.
Also, I think not all elisp packages should have file in
/etc/<emacs>/site-start.d: some may better use a (provide 'package) -
(require 'package) mechanism. (Rationale: it may be confusing, for a
user, to see Emacs menus in mail mode have changed, because his sysadmin
installed Mailcrypt behind the scenes, or, even worse, to have a very
different behavior in tex-mode, because his sysadmin has installed AUC
TeX).
I think package autoloading on their own main-function calls are fine with
/etc/<emacs>/site-start.d (calc is a good example), but package
autoloading on major modes (like tex-mode or {r,}mail-mode) are not, and
should be using (provide ...) - (require ...) instead.
(Since this means users will have to put a require form in their .emacs,
those package should tell'em about it in README.Debian. System
Administrators willing to load by default this sort of package could put a
require form in /etc/emacs/site-start.el.)
RB> Consider the proposal changed. The new emacs 20 package (which
RB> works as of today) puts all it's appropriate suff in /usr/share
RB> and /usr/local/share. I'll update the proposal shortly.
I plan to release AUC TeX and Mailcrypt using /usr/share as soon as the
new emacsen come out: is there an estimate time?
Thanks,
Davide G. M. Salvetti - IW5DZC [JN53fr]
Take a look at Debian GNU/Linux: <http://www.debian.org/>.
Debian is the free operating system with open development model.
Reply to: