bugzilla(a)bugzilla.redhat.com <bugzilla(a)bugzilla.redhat.com&gt; writes: In fact to see the problem it is sufficient to compare the output of (a) /usr/bin/xemacs-21.1.8 --help and (b) /usr/bin/xemacs-mule --help (and you can surely confirm that `/usr/bin/xemacs-noX --help` gives the same problem and xemacs-static too). Case (a) gives correct output for --help, but for (b) you see the garbled output from the "-help" line onwards. The problem is that the different XEmacs binaries ("xemacs-21.1.8", "xemacs-mule", "xemacs-noX", and "xemacs-static") are using the same "/usr/lib/xemacs-21.1.8/i386-redhat-linux/DOC" file, whereas a different "DOC" file is needed for every different binary. Looking at the Install section of "xemacs.spec" makes this clear: ---- Start of included text -----------------------8<--- cut here ------------- %install rm -rf $RPM_BUILD_ROOT cd building make install \ prefix=$RPM_BUILD_ROOT/usr \ lockdir=$RPM_BUILD_ROOT/var/lock/xemacs -C $RPM_ARCH-linux for i in static X11 mule noX ; do install -m 755 $RPM_ARCH-linux-$i/src/xemacs $RPM_BUILD_ROOT/usr/bin/xemacs-$i ---- End of included text -------------------------8<--- and here ------------- Proper installation as intended by the XEmacs developers only occurs for the standard xemacs binary build, for the other builds the binaries are just copied over by hand (although they have their own DOC files in their build "etc/" directories)... How to solve this? The easiest way from the users/installers point of view would be (see also my PS below) to make the separate executable packages conflict with each other and each containing their own DOC file (and "config.values" file too btw). To fix things keeping the current status quo of multiple executable packages, needs a little more thought, and would probably be best fixed by the XEmacs developers. I used to be an XEmacs developer/beta-tester, but unfortunately don't have time for that any more, so I'm cc'ing this to the xemacs-beta list and the maintainer of the JRPM60 xemacs packages to get their feed back too. I guess one solution would be to allow separate DOC files for each xemacs executable: this would require some (I think) minor changes to the xemacs sources and "src/Makefile", something like an option to add a given suffix to the xemacs executable name and the corresponding "DOC" and "config.values" files. Sorry this become so long. Best wishes, Jens ps I feel you have too many XEmacs packages: in my opinion just the basic xemacs, xemacs-mule (but with tty support please) and (?) maybe an xemacs-static should be quite sufficient for the majority of users. However I would recommend separating "/usr/bin/xemacs-%version" from the general xemacs package, to give people a decent choice. Eg personally I just need xemacs-mule with tty support, and I imagine many sites/users would be content with just installing and using one xemacs binary not five. (I know there are problems with the mule current support in a tty: I don't use mule in a tty, I just don't want to have to fire up a different binary when I'm in a console.)