On Wednesday 30 May 2007, Tom "spot" Callaway wrote:
On Wed, 2007-05-30 at 20:20 +0300, Ville Skyttä wrote:
> And both of those have a fundamental issue that they're disconnect
> with what
> we need - the rpm *package* version; unless of course emacs/xemacs add
> a versioned Provides or something like the httpd-mmn mechanism in the
> httpd package that aligns better with what can be retrieved from
> querying them or something non-rpm.
Do you really need that fine grained of a version? Is emacs/xemacs that
picky, that the API/ABI breaks on releases? That you have to match to
the exact package?
I can't speak for GNU Emacs, however I have some years of past experience as
the upstream XEmacs packages release manager, and I guess things aren't that
different with GNU Emacs. (Note: in this context, "package" has nothing to
do with rpm - think more like a CPAN module distribution tarball.)
The issue is not API/ABI breakage within XEmacs per se, but that a lot of
elisp packages (especially ones that aren't part of upstream XEmacs packages
collection and are thus likely candidates for being rpm-packaged separately)
aim for backwards source level compatibility by checking whether some
features exist in the XEmacs in use when the package is being run or
byte-compiled. If yes, they use what's available. If no, they provide their
own versions of missing functions, macros etc. This propagates into *.elc,
and quite a few functions do get added between upstream releases, especially
in the current beta branch of XEmacs that is being shipped in Fedora.
So let's say I byte-compile a package into *.elc with XEmacs 21.5.28. Elisp
package quux checks if the foo-bar function is available in the XEmacs being
used to byte-compile it. Yes, it is, so the internal backwards compat
version of foo-bar included in quux does not end up in the *.elc. Now, let's
assume foo-bar was added in XEmacs 21.5.28 and didn't exist in 21.5.27 and
we're trying to run the *.elc with 21.5.27 -> boom, foo-bar is not available.
Note: this wouldn't happen if only *.el were shipped - *.elc are the
potential and likely problem. Requiring >= version of the XEmacs used to
byte-compile the *.elc is not the only solution (nor enough for all corner
cases), but I can't think of a better generic way out that would be
appropriate for the vast majority of cases.