Re: XEmacs, TeX, and Re: Lengthy Debian install procedures
Rob Browning <rlb@cs.utexas.edu> writes:
> Steve Dunham <dunham@cse.msu.edu> writes:
>
> > It would be nice if we could come up with a different solution. I
> > guess I could always ignore all of the emacs packages and build my
> > own. Before I ran out of time, I would compile XEmacs myself.
> If you have a better solution that still keeps all the advantages we
> have now, I'm all ears...
No, "compiling XEmacs myself" is not a complaint about existing
packages. I can just avoid all of the issues you're trying to solve
by having one personal version of xemacs and using only that flavor of
emacs. (i.e. it's real simple if I'm the entire audience and XEmacs
includes _everything_).
> A solution must:
> 1) Support running install-scripts for each of the installed flavors
> of emacs (among other reasons, this is because different emacs
> are not always byte-compiled file compatible, and we can't have a
> separate binary pacakge for each add-on package for each emacs
> flavor -- the storage space would be tremendous, and it would
> require all emacs add-on package maintainers to have *all*
> flavors of emacs installed on their machine to do the builds).
Actually, I'm willing to assume that disk space is cheap and abundant
on the developer's machine, but I agree that keeping the size of the
ftp site (and CDROMs) under control is important.
> 2) support for install time (during dpkg-runs) dependencies between
> emacs add-on packages (i.e. cvs-pcl depends on elib) so that you
> can dynamically order the install/remove add-on package script
> runs based on what is (or is currently being) installed.
> 3) support for handling installs/removes of a main emacs package
> (including cleaning up all the stuff that was added for that
> particular flavor by all the add-on packages).
> 4) Something else I've probably forgotten.
The emacs issue seems fairly intractable (actually there may be one
solution, but it involves tweaking dpkg and is not worth it, namely:
multiple data.tar.gz parts in the .deb file). So I guess we should
leave it as "it would be a bit better with post-install-hooks".
As for the TeX issue: I suspect the reason for recompilation on
upgrade is local changes to /etc/texmf/{language.dat,modes.mf}. One
improvement would be to include format files for the default
configuration files, and if the user hasn't changed those config
files, install the replacement *.fmt, otherwise recompile. The
question is: is it worth the added complexity for the time savings?
One specific way to implement this is to make the /etc/texmf/* and
*.fmt files conffiles, and have post install check to see if the ones
in the filesystem match the distributed ones - skipping recompile if
it is true.
Steve
dunham@cse.msu.edu
Reply to: