Bug 85626
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> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 1.0 | CC: | srevivo |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2003-04-08 11:28:16 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Chris Green
2003-03-05 08:18:26 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. 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. |