Bug 75608 - Emacs should be installed even when X isn't
Summary: Emacs should be installed even when X isn't
Alias: None
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: redhat-release-as
Version: 2.1
Hardware: ia64
OS: Linux
Target Milestone: ---
Assignee: John Flanagan
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2002-10-10 08:13 UTC by Johan Walles
Modified: 2007-11-30 22:06 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-09-23 18:13:35 UTC

Attachments (Terms of Use)

Description Johan Walles 2002-10-10 08:13:20 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020607

Description of problem:
If you choose not to install X during installation, Emacs won't get installed
either.  The base Emacs package gets installed but neither emacs-nox or
emacs-x11 does.

I want Emacs to get installed even if I don't install X.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Get an IA64 machine and a copy of RHAS
2. During installation, go with the easy route (i.e. not the customized install)
3. Deselect X11 when you get the chance.
4. After installation is done and you have rebooted, log in as whoever and type
"emacs" at the prompt.

Actual Results:  bash: emacs: command not found

Expected Results:  Emacs should have been started.

Additional info:

As I said before, neither emacs-nox nor emacs-x11 gets installed.  I would
prefer if emacs-x11 (and thus libxaw3d) got installed regardless of whether the
user wants X on the server or not.  That I don't want a GUI on the server
doesn't mean I don't want X in a window when ssh:ing in.

Feel free to lower the severity to "enhancement" or "low" if you think "normal"
is too high.  Personally I feel quite handicapped without Emacs so for me this
one feels more like "normal: it's a bug that should be fixed", than "low: minor
loss of function or problem where easy workaround is present".

Comment 1 John Flanagan 2005-09-23 18:13:35 UTC
RHEL2.1 is in maintenance mode at this time.  Packaging changes are no longer
occurring.  Apologies for having this one slip through the cracks.  RHEL2.1 had
pretty rigid packaging constraints that were lifted in RHEL3, RHEL4 and Fedora
due to more flexible packaging design.

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