Bug 85626 - rebuilt xemacs-21.4.12-6 doesn't find site-start.el
rebuilt xemacs-21.4.12-6 doesn't find site-start.el
Product: Red Hat Raw Hide
Classification: Retired
Component: xemacs (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jens Petersen
Jay Turner
Depends On:
  Show dependency treegraph
Reported: 2003-03-05 03:18 EST by Chris Green
Modified: 2015-01-07 19:04 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-04-08 07:28:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Chris Green 2003-03-05 03:18:26 EST
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):

How reproducible:

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
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 .
Comment 1 Jens Petersen 2003-03-18 20:35:35 EST
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.
Comment 2 Chris Green 2003-03-27 15:39:18 EST
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?

Comment 3 Chris Green 2003-03-27 15:52:41 EST
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?

Comment 4 Jens Petersen 2003-04-08 07:28:16 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.