|Summary:||rebuilt xemacs-21.4.12-6 doesn't find site-start.el|
|Product:||[Retired] Red Hat Raw Hide||Reporter:||Chris Green <greenc>|
|Component:||xemacs||Assignee:||Jens Petersen <petersen>|
|Status:||CLOSED UPSTREAM||QA Contact:||Jay Turner <jturner>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2003-04-08 11:28:16 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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): 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 .
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? Thanks, Chris.
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? Thanks, Chris.
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.