Re: Mailcrypt - EMACS package maintainers please read this message.

[Rob Browning <rlb@cs.utexas.edu>]

"Davide G. M. Salvetti" <salve@debian.org> writes:

> If you're going to install XEmacs20, tm is supposed to have to byte
> compile just for XEmacs20; it should already have been called at its
> (tm's) installation time to byte compile for other emacsen (or when the
> other emacsen where installed) and it should have already done flavor
> independent things it may have needed (I mean, the first time it was
> called, at its installation time).  Am I wrong?

Ok, I think maybe you've convinced me.  Let me see if I understand
the modification you're proposing:

  1) emacs installation, call

       emacs/install/* <flavor> <other-installed-flavor> ...

     for the flavor being installed.

  2) add-on package installation, call

       emacs/install/* emacs    <installed-flavor> ...

     and  

       emacs/install/* <flavor> <other-installed-flavor> ...

for each flavor already installed.  The removal scripts would be
symmetric.

One problem (which is not specific to this approach) is that I don't
fully understand how dpkg handles multiple installations.  What I was
worried about is something like:

  dpkg -i emacs19.deb emacs20.deb tm.deb auctex.deb emacsen-common.deb

Are there any guarantees about the order that the postinst
scripts fire?

> It will be done in the next release.  BTW: I don't like the current script
> name (auctex-auto-load), I'd rather have update-tex-elisp, but I hesitate
> to change it, in the event someone already relies on it.

You could put a symlink, and only document the new name.  It's a
little ugly, but it won't hurt.

> I told you that since you're really going to extensively update emacs
> packages policies: I think we could add suggestions [1] of this type too,
> but maybe it's better to have another, smaller, proposal about these minor
> things.

You may be right, but I've got my hands full just getting this initial
conversion set up, and I hate to pile even more on top of the add-on
package maintainers when I'm already asking all of them to rework
their code.  In any case, I don't think we're doing anything now that
precludes doing this stuff later, but if you have a good proposal, I'd
be happy to hear it.

> No thanks, I don't have very much free time now, better wait for the new
> emacs19, before I start playing with it (I have no spare machines handy
> and I have to use Emacs every day).

Can't blame you for that :>

-- 
Rob Browning <rlb@cs.utexas.edu>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94  53 2B 97 F5 D6 4E 39 30