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. -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
