Re: Mailcrypt - EMACS package maintainers please read this message.
>>>>> "RB" == Rob Browning.
RB> Ok, I think maybe you've convinced me. Let me see if I understand the
RB> modification you're proposing:
RB> 1) emacs installation, call
RB> emacs/install/* <flavor> <other-installed-flavor> ...
RB> for the flavor being installed.
RB> 2) add-on package installation, call
RB> emacs/install/* emacs <installed-flavor> ...
RB> and
RB> emacs/install/* <flavor> <other-installed-flavor> ...
RB> for each flavor already installed. The removal scripts would bes
RB> symmetric.
Exactly!
BTW, I don't remember if we have ever discussed about it, but I also think
add-on packages should byte-compile in background [1], since it could be a
quiet long job. They should also provide a log.
[1]: It would be nice if the user could choose whether to have background
or foreground byte-compilation, but this may be a bit unfair with respect
to unattended installation (the less you ask the user, the better,
especially on new (not upgrade one) installation).
RB> One problem (which is not specific to this approach) is that I don't
RB> fully understand how dpkg handles multiple installations. What I was
RB> worried about is something like:
RB> dpkg -i emacs19.deb emacs20.deb tm.deb auctex.deb emacsen-common.deb
RB> Are there any guarantees about the order that the postinst scripts
RB> fire?
I think we may be confident that dpkg will never configure a package
depending on another one before this last one has been configured (unless
dpkg was forced, of course). So emacsen-common.deb should be the first
one to be configured, than emacs19.deb and emacs20.deb, and only then the
others.
I'm not sure, but I think issuing a line like that would probably result
in 4 half installed package (emacs{19,20}, tm, auctex), reissuing would
leave 2 half installed package (tm, auctex) and issuing the same line
another last time should fix them all. (Obviously after the first time
one should better use --configure rather than --install, unless some
package predepends on some other one, of course).
> 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.
RB> You could put a symlink, and only document the new name. It's a
RB> little ugly, but it won't hurt.
Yes, thanks, I think I'll follow your suggestion: I will call the script
update-auctex-elisp, to be sure it will be unique (update-tex-elisp
doesn't contain auctex). I will warn users not to use the old name and
eventually remove it some time in the future.
RB> You may be right, but I've got my hands full just getting this initial
RB> conversion set up, and I hate to pile even more on top of the add-on
RB> package maintainers when I'm already asking all of them to rework
RB> their code. In any case, I don't think we're doing anything now that
RB> precludes doing this stuff later, but if you have a good proposal, I'd
RB> be happy to hear it.
Ok, let's do this in two step and wait your proposal is inserted in the
policy first.
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: