emacs and /etc/alternatives

[Toshio Kuratomi]

On Fri, 2007-03-09 at 12:27 -0500, Chip Coldwell wrote:
> 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.
> 
Right.  The scripted approach, that is already implemented, is the one
that people support.  If you're just going to bow to the will of the
people, then that's what you need to do.

> > 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?

Because it's incredibly easy for people to argue in the abstract about
what's "right" and what's "wrong".  Give people some concrete objectives
that they need to solve (reconcile rpmlint's output with the needs of
this package) and they'll contribute something useful rather than just
spouting ideas that other people shoot down.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-maintainers/attachments/20070309/1b900bdf/attachment.sig>