Bug 85626 - rebuilt xemacs-21.4.12-6 doesn't find site-start.el
Summary: rebuilt xemacs-21.4.12-6 doesn't find site-start.el
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: xemacs
Version: 1.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jens Petersen
QA Contact: Jay Turner
Depends On:
TreeView+ depends on / blocked
Reported: 2003-03-05 08:18 UTC by Chris Green
Modified: 2015-01-08 00:04 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-04-08 11:28:16 UTC

Attachments (Terms of Use)

Description Chris Green 2003-03-05 08:18:26 UTC
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-19 01:35:35 UTC
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 20:39:18 UTC
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 20:52:41 UTC
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 11:28:16 UTC
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.