Re: Debian is not a "main distro"?
Rob Browning <rlb@cs.utexas.edu> writes:
> Steve Dunham <dunham@cse.msu.edu> writes:
>
> > In addition to the packager apparently being slower, and the
> > unnecessary interaction, many Debian packages do a lot of unnecessary
> > computation: recompiling elisp files 3 or 4 times, recompiling TeX
> > formats, etc.
> I think that any given add-on shouldn't have it's elisp compiled more
> than once per installation per emacs flavor. Actually it might be
> twice, but not 3 or 4 times. Are you sure?
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). Maybe it only did it once,
If I get some time, I'll do an install again and make sure.
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.
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.)
> Also, if RedHat doesn't do something like this (and I suspect they
> don't) then they can't do what we can do with respect to emacsen.
> There's no reasonable way around this process that still supports byte
> compiled files for every installed flavor of emacs.
Red Hat chooses one version of emacs and they don't have an auctex
package, so they don't deal with this problem. So they DTRT, but have
less flexibility.
If I had a better solution, I would definitely let you know. Emacs
does retain some bytecode compatibility.
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.)
> > While Debian is easier to upgrade, and Debian packages seem to be of
> > a higher quality, Red Hat has Debian beat on installation.
> In some cases they may just have a better (faster) way of handling the
> situation, but in many, they may just not be "DTRT".
The RPM package system seems a bit faster. It is definitely faster at
initializing itself before installing packages, and for certain types
of queries. Debian's interaction slows the process down too.
When I get some time, I'll go through another install and take notes
on what parts are particularly slow.
I'd also really like to see our source package stuff fixed. At the
very least, I'd like to see support for multiple upstream tar files.
(Multiple diff files would be nice too.)
Steve
dunham@cse.msu.edu
Reply to: