For those who haven't noticed, FE6 will ship XEmacs 21.5.x. Additionally, I've recently realized that stuff in the xemacs-sumo package is not really built from sources; only patched *.el have been recompiled to *.elc, and the majority of upstream byte-compiled *.elc are shipped as-is. It's time for that to change, but it requires some packaging changes too. Warning: longish mail containing thinking aloud and some instructions follows. Not that it would really necessarily deserve this long an explanation, but I just wanted this dump somewhere out for reference. (Maintainers of XEmacs related packages in FE also Bcc'd in case they're not on the list.) Currently, the few bits in xemacs-sumo that are actually rebuilt are done so using the xemacs-nox package, without xemacs-nox having any dependencies to xemacs-sumo in order to avoid a build dependency loop, ie. a bootstrap problem. However, that won't work when everything is built from sources; some bits require a XEmacs that has X support to build. The main xemacs package currently has a dependency on xemacs-sumo, that has to go too in order to avoid just moving the build dep loop elsewhere. So, I'm planning to reorganize things for FE6, but exactly how to do it is still an open issue. First, one plan is to split xemacs-sumo to two. The smaller bit, xemacs-packages-base, will contain packages that upstream considers the minimal set: xemacs-base, efs, and mule-base. This will be compiled with xemacs-nox, and will be enough for people who choose to manage rest of the upstream lisp packages using XEmacs's built in tools instead of installing them from rpms. The second part, xemacs-packages, will contain practically rest of the current sumo and it will be compiled with the main X-enabled xemacs. These packages will not be called "sumo" because they no longer quite represent what upstream calls sumo either. Backwards compat Provides/Obsoletes will be there, naturally. Second part of the above plan is that the main xemacs package will no longer have a dependency to xemacs-packages (ex-sumo, due to the build dep loop above); it will have a dependency on xemacs-packages-base only. So this is what it would look like (versions dropped for brevity): xemacs: dep on xemacs-common, xemacs-packages-base, provides xemacs(bin) xemacs-nox: depends on xemacs-common, provides xemacs(bin) xemacs-common: no xemacs* deps xemacs-packages-base: depends on xemacs-common xemacs-packages: depends on xemacs-packages-base The most significant change for users and packagers is that the main xemacs package will no longer pull in all the xemacs lisp packages formerly in Sumos. Users who upgrade will get the same functionality, but ones who install from scratch, will need to install xemacs-packages in addition to xemacs to get the same lisp bundle as was earlier pulled in by just xemacs. But packagers should be aware of the changes, too. I looked into current FE packages that have some XEmacs things, and it looks like some work is required in all of them, some less, some more. This is "IMO", not a policy, and not all findings are related to the xemacs-sumo split, and some are applicable to GNU Emacs lisp packaging too. Here's a rough checklist for runtime dependencies: 1) Makes sense with full featured xemacs only, not -nox -> Requires: xemacs. Additionally, if it requires something from xemacs-packages -> Requires: xemacs-packages - as said above, that's no longer pulled in by the main xemacs package. 2) Makes sense both with full featured and -nox -> Requires: xemacs(bin). Additionally, if it requires something from xemacs-packages -> Requires: xemacs-packages. If not, but requires something from xemacs-packages-base -> Requires: xemacs-packages-base (because -nox does not and can't have a dep on xemacs-packages-base - that'd result in a build dep loop). 3) Ships *.elc (IMO everything that is not a simple init-like file dropped to site-start.d should be byte-compiled into *.elc during build!) -> Requires: $xemacs >= $version (versioned!), where $xemacs is xemacs or xemacs(bin) determined by 1) and 2) above, and $version is the version of xemacs (or -nox, see build stuff below) that was used to compile the *.elc. An example how to take care of the version part will be included in the upcoming xemacs-packages and xemacs-packages-base packages. The version is important because there are no backward compatibility guarantees for *.elc. One specific example is that Requires: xemacs-common is most likely a packaging bug and should be changed to (a versioned) Requires: xemacs or Requires: xemacs(bin) as appropriate. Build time dependencies: a) Can be built with xemacs-nox -> BuildRequires: xemacs-nox. If also requires something from xemacs-packages to build -> BuildRequires: xemacs-packages. If not, but requires something from xemacs-packages-base to build -> BuildRequires: xemacs-packages-base. b) Can not be built with xemacs-nox, requires full featured xemacs to build -> BuildRequires: xemacs. If additionally requires something from xemacs-packages to build -> BuildRequires: xemacs-packages. For simplicity, b) could be applied to all xemacs lisp packages, but deciding between a) or b) as applicable allows for a more optimized/minimized set of build dependencies. Open issues: - Is xemacs(bin) is a good name for the Provides provided by xemacs and xemacs-nox? One alternative would be to rename the current main package to let's say xemacs-x, leave xemacs-nox as is, and have xemacs-x and xemacs-nox simply provide "xemacs" instead. This would however be slightly less backwards compatible in the "install from scratch" case than the xemacs(bin) approach. - Would it be better to fold all the sumo/lisp package things back to the main xemacs source rpm? This would allow making some things a fair bit simpler, and would also make it possible to drop xemacs-nox altogether; as long as emacs-nox exists, I'm not sure if anyone really needs it. The drawbacks of the bundling would be kind of gratuitously arch-specific lisp subpackages (OTOH in rpm arch only, the content would continue to be arch independent) and that updates for the whole shebang would need to be shipped all at once. Hm, strange. Having written the last paragraph, I'm starting to lean towards it ;) (including dropping xemacs-nox). Comments welcome, either on or off list - I'd like to have a firm plan how to proceed at end of this week. -- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
