David Kastrup <[EMAIL PROTECTED]> writes:
> Sure. But emacs23-snapshot suggests some compatibility with Emacs23.
> That is not the case. Nothing compiled for one snapshot is
> guaranteed to work with the next snapshot.
This would only be an issue if .elc files were preserved across
upgrades. This is not the case with the emacs and xemacs packages that
are distributed by Debian. The `prerm' script calls
/usr/lib/emacsen-common/emacs-remove ${FLAVOR}
and after the new version has been installed, its `postinst' script
calls
/usr/lib/emacsen-common/emacs-install ${FLAVOR}
The former removes all .elc files for ${FLAVOR} that have been
generated from separately distributed Elisp packages and the latter
recompiles them with the new version.
>> I see two reasons for calling the packages emacs23-snapshot* as
>> opposed to emacs-snapshot:
>>
>> a) There'd be a sane upgrade path once Emacs 23 is released.
>
> Not more or less sane than with emacs-snapshot.
It's possible, but one would have to declare versioned Conflicts in
the final emacs23 package.
>> b) Elisp packages can specify for which package they should be
>> byte-compiled. A package that has worked fine with a pre-Emacs22
>> snapshot package might fail once a post-Emacs22 snapshot package if
>> we keep the name `emacs-snapshot'.
>
> A compiled package that has worked fine with one version of any
> snapshot can fail with any next snapshot.
As mentioned above, this isn't a problem for the byte-compiled code.
And if a package exposes bugs in emacs23-snapshot or vice versa, this
should make great QA opportunities on the path to Emacs 23. :-)
> In fact, this happens fairly regularly in Emacs' integrated Lisp
> packages, every few months or so. When this happens, one needs to do
> "make bootstrap" instead of the usual "make recompile" to get a
> working Emacs again.
The .elc files that are part of Emacs are compiled with the right
version when the package is generated, so this doesn't pose any
problem, either. Emacs instances that are kept running while an
upgrade is performed will be affected when they try to load code that
has been compiled with the new version. But that's what users of the
`unstable' distribution should expect when running -snapshot packages.
(The problem and possible workarounds should be described in
README.Debian.)
Am I missing anything else?
-Hilko
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
