Re: Debian is not a "main distro"?
Steve Dunham <dunham@cse.msu.edu> writes:
> I was referring to recompiling once for each version of emacs
> installed (when I installed using the predefined package sets and apt,
> I ended up with both emacs20 and emacs19).
This is a bug. Someone needs to file a bug against ftp.debian.org. I
think last time this came up, people thought that emacs20 shouldn't be
standard, only emacs19. I thought it had been fixed. I don't have
time to look into it ATM, so if someone else wants to...
> IIRC, the auctex package took a particularly long time on my laptop.
> I'll try to pay more attention next time I install. I thought I saw
> it go twice, but I might be mistaken.
You should try calc :>
Whenever an emacs flavor is installed, the install scripts for each of
the add-on packages must be called at least twice. The first call is
for the package to do flavor independent stuff, and the second is for
that particular flavor. Add-on packages can ignore either or both of
these calls, and there should be enough information in the argument
lists for the scripts to know what not to do.
> The big questions are: does upgrading (e.g.) emacs19 cause everything
> to be recompiled? (This seems to happen with tetex - upgrading to a
> new Debian release of the same version causes stuff to be recompiled.)
This has to be the case. In general, it isn't possible to know that
minor changes (even debian specific ones) don't require a recompile of
the byte compiled files. Only the pacakge maintainer can know that,
and it can be pretty tricky to determine. And then they'd have to
have a lookup table or something in the scripts that say which
versions need recompiling since people often skip package versions.
I worked out a fairly sophisticated scheme to help with this, but
never got time to make sure it would work and implement it. The other
problem is that if any of the *external* elisp that the package
depends on containes macro definitions that the package source uses,
then the .elc files must be recompiled. It's like changing the struct
size incompatibly in a system header, but even worse.
> The Debian mechanism is nice, I just wished there was a way to speed
> up the install. (It doesn't matter too much since I usually use
> xemacs.)
I hear xemacs is about to have the same problem, but to a much greater
degree. They're breaking out *all* the internal packages upstream.
If I get the time, I'll try to find the message I sent about reducing
redundant recompiles and see what I think about it now, but don't hold
your breath, it's a nasty little problem.
--
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930
Reply to: