Re: Taking over production of emacs20 package.
"Adam P. Harris" <apharris@onshore.com> writes:
> What's uncoordinated? Major Emacsen release versions are going to
> naturally have different localize configurations. I think it would be
> more awkward to try to unify all these (though it could be done -- still,
> what package would the site-start.d files ship with?).
This is a question I was going to get around to asking, but I hadn't
finished familiarizing myself with what's already going on in the
emacs and xemacs packages. While it's obvious to me that for the most
part, the three emacsen will have separate code trees, I do think
there's a place for shared files.
As a simple example, there's the debian-changelog-mode.el file which
is currently handled on a special case basis by xemacs. dpkg puts the
file into /etc/emacs/site-start.d, and then xemacs checks for it and
symlinks it into /etc/xemacs/site-start.d. This seems a pretty weak
solution, and one that won't scale.
Here's the issue as I see it (bear with me because I'm just getting a
handle on the emacs .el file issues myself). I think that we should
have some sort of install procedure (a la install-info) for emacs .el
files. This tool/procedure should make sure that all the emacs
versions that can handle a particular set of .el files know where to
find them, and (depending on local policy?) will byte-compile them on
install.
For .el files that are specific to a particular emacs, we have no
problem. These files just go in /foo/{x,}emacs{20,}/ and won't
interact with the other packages.
For .el files like debian-changelog-mode.el that are generic enough
elisp that they should work with any emacs (19, 20, or x) we need a
shared directory or something. The only problem with this is that
when the files are byte-compiled there's a naming conflict since at
least xemacs and GNU emacs don't speak the same byte-code right now.
Because of this foo.el would need to produce two (or three) .elc
files, one for each emacs.
I can see several ways to handle this:
1) have the automated .el install tool use lndir (or similar) to make
sure that each emacs has a symlink mirror of the contents of the .el
files in the common directory and then generate the .elc files in the
shadowed directory.
2) have a naming convention in the common directory where each emacs
that can handle a particular file symlinks to a particular name and
uses that file (i.e. foo.el might be symlinked as foo.xemacs.el and
foo.emacs20.el, but not foo.emacs.el). The debian-rundir code would
have to be updated accordingly, and this wouldn't help at all for
packages where we don't control the name of the source files.
3) Have each emacs redirect the byte-compiled files to a emacs version
specific directory (i.e. /var/lib/xemacs-20/site-start-elc/) and make
sure this path preceeds /etc/emacs-common/site-start.d/ in the load
path.
In my opinion, option 2 is pretty weak, and 3, if it works is my
favorite so far.
> In general, the place where the user should install local lisp files, if
> I'm not mistaken, is /usr/local/lib/emacs/site-lisp. Is this correct?
> Probably all Emacsen should ship to include this dir on the lisp-library
> path.
At least emacs does, and emacs20 will too.
> I'm going to CC debian-policy list here. I agree that the Emacs
> directory issue needs to be formally documented, either in the packaging
> manual or the policy.
I agree, but I sort of felt that it should stay on debian-devel for a
while until we get more input. Once we move it over to debian-policy,
the audience will be much more limited. That's good for finalization,
but maybe not so good for brainstorming.
--
Rob Browning <rlb@cs.utexas.edu>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
Reply to: