Chip Coldwell writes: > On Fri, 9 Mar 2007, Toshio Kuratomi wrote: > 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? The problem is that the suggested changes are disproportionate. We already have a neat and painless solution to the problem. However, rpmlint can't cope with it. But rpmlint is to help people to find out when something is wrong and change things, not to force people to change things that aren't wrong. At the moment, the only thing that is wrong with the solution we have is that rpmlint can't grok it. Andrew. -- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
