Re: Mailcrypt - EMACS package maintainers please read this message.
"Davide G. M. Salvetti" <salve@debian.org> writes:
> 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.
It's so that if a script has no flavor dependent stuff, it can just
react to an "emacs" first argument and ignore any others. Any scripts
that do byte-compiling will probably do the opposite (that is, only
react to a non "emacs" fist argument). I know it's a little
redundant, but it doesn't hurt anything, and it allows the add-on
package maintainers more control over how they structure their
scripts.
> 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.
Well, the ${elc_dir} here is the add on package's directory, so there
anyone who put anything else in there is asking for trouble. The
add-on package effectively owns
/usr/share/<emacs>/site-lisp/foo/
where foo is the name of the add-on package, and it can do what it
likes in there. That's part of the proposal.
> 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.
You're right to complain here, this was a typo; It's corrected in the
more recent version of the proposal (1.1). It should be:
rm -f /usr/share/${FLAVOR}/site-lisp/foo/*.elc
instead of
rm -f /usr/share/${FLAVOR}/site-lisp/*.elc
> 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.
Again, since each add-on package has it's own subdirectory
"playground", I don't see that this is necessary.
> 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?
OK, I hadn't thought of that, but I'd say that you should document
that you need to call update-tex-elisp script after changes to
/usr/local, and then the cron task can stay around as a catch-all.
> 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).
[ other good stuff about site-start.d elided ]
I think most of this will have to be left as a package by package
decision. But in general, I agree that there either needs to be a way
to "turn the package off" for those users on a given system that don't
want it always loded for them, or just not have it loaded
automatically at startup.
At the very least, the site-start.d mechanism should be used to make
sure that load-path contains the package's relevant directories, and
that autoloads are set up properly. I think tm already does require
you to do something to "turn it on".
> I plan to release AUC TeX and Mailcrypt using /usr/share as soon as the
> new emacsen come out: is there an estimate time?
Well, I'm ready to go, but we really have to wait for a new emacs 19
package that knows about emacsen-common. I could go ahead and upload
emacs20 to experimental, and you could start playing with that, but
it'll require that you purge emacs 19 and all the packages that depend
on it. Let me know if you're interested.
--
Rob Browning <rlb@cs.utexas.edu>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
Reply to: