emacs and /etc/alternatives

[Chip Coldwell]

On Fri, 9 Mar 2007, Toshio Kuratomi wrote:

> On Fri, 2007-03-09 at 09:12 -0500, Chip Coldwell wrote:
> > 
> > Well, then I guess my preference would be to eliminate the -nox subpackage 
> > from Fedora.  We can continue to support it for RHEL, since there will be 
> > headless servers, etc, that don't need all the GUI infrastructure.
> > 
> You're going to find that some reviewers balk heavily at this.  Perhaps
> even enough to veto a package that another reviewer is willing to
> approve.  Luckily I don't use emacs so I don't have to get involved with
> that one :-)

If you've been following this thread, you must realize that I am just 
blowing with the wind here.  My initial notion was to use the 
/etc/alternatives infrastructure.  That's what Debian does, and it seems 
like this is precisely the sort of thing that /etc/alternatives was meant 
to handle: two alternative methods of providing the same (or nearly the 
same) functionality.  We could even fold in xemacs.

That met with strenous objections.

Then I suggested having two packages that conflict with each other.

That met with strenous objections.

Then I suggested dropping the emacs-nox package.

That met with strenous objections.

> What would be most productive in this conversation, though, is posting
> the reason that you're thinking of changing the way emacs builds and
> installs.

I suppose I could, but given how this thread on a much narrower topic has 
gone, what hope is there of reaching consensus on the entire rpmlint 
output?

Chip

-- 
Charles M. "Chip" Coldwell
Senior Software Engineer
Red Hat, Inc
978-392-2426