Re: [debs] Emacs + XFT
Romain Francoise wrote:
The DOC file is strongly tied to the Emacs binary as dumped during the
build, so it's recommended to ship it with the binary itself. But now
that I look into it, I see that the three files are identical:
[...]
... the file is just copied over from the -common directory when
installing the files in the packages, which is rather strange.
Unfortunately the reasons why the Emacs packages are laid out like
that are lost in the mists of time.
I guess I could move that to -common and save a few megs off the
combined size of the binary packages.
If the DOC file is identical for every architecture, yes. I think it
should be, but you had better double-check this.
/usr/bin/emacs-snapshot
That would have to become (yet another) alternative instead of a plain
symlink. Users would then have an 'emacs-snapshot' alternative as well
as the traditional 'emacs' alternative.
/usr/share/man/man1/emacs-snapshot.1.gz
Ditto, as a slave to the first alternative.
Is this correct, or are there other reasons that they conflict?
Other small things: if both the -x and -gtk packages are installed then
the menus will have multiple 'Emacs Snapshot (X11)' entries; ditto for
the .desktop entries (which affect the GNOME/KDE menus). But to be
honest, I wouldn't mind redoing the menu handling from scratch, I
inherited it from the emacs21 package and didn't change things for
coherency, but I think it sucks.
And also, another reason is that the 'emacs' alternative would list -x,
-gtk and -nox as valid options, but that could be seen as a feature
rather than a bug. (Right now it only lists one version from emacs21,
and one version from emacs-snapshot.)
You did not mention what I think will be the biggest problem: The
handling of add-on packages in the maintainer scripts. If you
install multiple binaries of the same emacs flavor, you want to
byte-compile the Elisp files only once. And if you remove one, but not
all of the binaries of a flavor, you must not purge the byte-compiled
files in the prerm script. I do not think that emacsen-common can
currently handle these situations. :-(
So yeah, it involves some work... and now that it's halfway done, I
might as well just do it. :-)
Go on, and good luck!
Cheers,
Sven
Reply to: