>>>> "M" == Michael Kifer
>>>> "MB" == Martin Buchholz <of Tue, 29 Dec
1998 16:28:16 PST> writes:
MB> We could unilaterally change all our names to
MB> be prefixed with `x', but....
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.