M> Does anybody know why redhat distributions don't include xemacs? M> Did anybody approach them with this? I approached them a couple of years ago. Their attitude is that xemacs comes with the Red Hat Powertools, and the `normal' Red Hat contains Emacs. There is probably a space issue including emacs and xemacs both. There is also a conflict with a few files, like gnudoit. Martin

M> This should be fixed. I remember that I also had problems with installing M> the xemacs rpm because of the conflict with the gnuserv rpm. M> This conflict might be turning off other potential users. This is tough to fix. We could unilaterally change all our names to be prefixed with `x', but.... xctags xetags xgnudoit xgnuserv ... but that would only increase the confusion about xemacs being an X11-only app, besides being amazingly ugly. And break all the user's scripts. I'm open to realistic suggestions on how we actually implement this. Martin

MB> We could unilaterally change all our names to MB> be prefixed with `x', but.... MB> xctags MB> xetags MB> xgnudoit MB> xgnuserv MB> ... MB> but that would only increase the confusion about xemacs being an MB> X11-only app, besides being amazingly ugly. And break all the user's scripts. MB> I'm open to realistic suggestions on how we actually implement this. M> As far as gnuserv is concerned, this can be unbundled and xemacs can rely M> on the gnuserv.rpm in RedHat's contrib. I think part of the problem is that gnuserv's have evolved independently, and our gnuserv and FSF Emacs' gnuserv are no longer compatible. Someone correct me if I'm wrong. M> What exactly is the problem with ctags? Is it bundled with emacs.rpm? M> If so, I can see two solutions: M> 1. The etags and ctags things can be installed in a different directory M> than the one used by emacs.rpm A directory unlikely to be on the user's path. Many users have scripts that run etags/ctags, and when the next xemacs install happens, they will either not get an etags/ctags, or the old version will not get overwritten and bitrot will set in. M> 2. Better yet, e/ctags might be better off as a separate package, and redhat M> might agree to unbundle them from emacs.rpm Red Hat does not yet have monopoly-style market share in the operating system market. Certainly Red Hat can create special rpms specifically designed for a Red Hat environment that work properly, but that does not solve our problem as to what a vanilla `make install' should do. Martin