[Fedora-packaging] Packaging guidelines for Emacsen add-on packages

[Ville Skyttä]

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.