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):
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:
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
(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.
Putting a soft link in as follows:
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?
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?
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.