From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021204 Description of problem: After recompiling 21.4.12-6 from SRPM, site-start.el is not found in its installed location of /usr/share/xemacs/site-packages/lisp/site-start.el Instead xemacs appears to look for it in /usr/lib/xemacs/xemacs-packages/lisp/. First, an admission: I'm backporting this to RH7.3 by taking the SRPM and recompiling after replacing db4 with db3 and autoconf213 with autoconf in the SPEC file. HOWEVER: this should be reproducible on a genuine rawhide test system as described in the following sections If this is not reproducible in a genuine RawHide environment, then I apologize for wasting your time, but I believe the fact that I'm backporting as described above has nothing to do with it and there is a problem with the package. Version-Release number of selected component (if applicable): 21.4.12-6 How reproducible: Always Steps to Reproduce: 1. Get the SRPM. 2. Install it with rpm -ivh xemacs-21.4.12-6.src.rpm. 3. Recompile with rpm -ba /usr/src/redhat/SPECS/xemacs.spec. 4. Remove any existing xemacs installation with rpm -qa | grep '^xemacs' | xargs rpm -e --nodeps. 5. Install it with rpm -Uvh /usr/src/redhat/RPMS/i386/xemacs-21.4.12-6.i386.rpm. 6. Start it with xemacs -q and check recent messages to see what was loaded. Actual Results: Recent keystrokes: misc-user Recent minibuffer messages (most recent first): Expected Results: If site-start.el was loaded, the contents of /usr/share/xemacs/site-packages/lisp/site-start.d would have been loaded. On a vanilla install of xemacs this should be psgml-init.el. Alternatively, putting the line: (message "Loading site-start.el") at the top of the site-start file would have put the above message in the recent messages buffer had it been loaded. Additional info: Putting a soft link in as follows: cd /usr/lib/xemacs/xemacs-packages/lisp/site-start.el ln -s /usr/share/xemacs/site-packages/lisp/site-start.el .
What happens if you rebuild it without xemacs installed? I suspect the recent move of xemacs packages from /usr/lib to /usr/share is related to what you're seeing. XEmacs' package root bootstrapping is, shall we say, a little delicate.
Sorry for the delay getting back to you. I have successfully built xemacs-21.4.12-6 from SRPM using, as you suggest, a completely xemacs-free system. HOWEVER, that brings up the following oddities: aspell still puts its lisp file under /usr/lib rather than /usr/share, apparently even if I rebuild aspell from source. apel has a circular dependency: it requires xemacs to build, yet xemacs requires apel-xemacs to install. What is the safest way to resolve this? If I build xemacs from SRPM without apel installed, then install xemacs --nodeps, and then rebuild apel from SRPM, this appears to work. Are there any GOTCHAs waiting for me? Thanks, Chris.
One thing I forgot to mention: the rebuilt RPM now has a directory /usr/lib/xemacs-21.4.12/i386-redhat-linux, the use of which is unclear. Is this intentionally part of the package or has it crept in by mistake? Thanks, Chris.
Yep, aspell needs fixing - thanks for bringing it up. See bug 88262 which I just submitted. I agree the apel-xemacs dep is a little ugly, but since we have the separate apel package for emacs this was still better than having to update apel in two packages. As you point out there is in principle a bootstrapping dilemma, but I recommend installing apel-xemacs (it's noarch), before rebuilding xemacs. As for /usr/lib/xemacs-21.4.12/i386-redhat-linux, yes it is for arch-specific auxillary files. I'm not sure if anything can to done to avoid the original problem you reported. I believe the XEmacs Team are aware of the issue and intend to fix this one day. In the meantime the above workaround is probably the simplest.