emacs and /etc/alternatives

[Toshio Kuratomi]

On Fri, 2007-03-09 at 09:12 -0500, Chip Coldwell wrote:
> On Thu, 8 Mar 2007, Jesse Keating wrote:
> 
> > On Thursday 08 March 2007 16:59:36 Chip Coldwell wrote:
> > > Right now: if you install emacs it drags in gtk/gdk/atk/etc, but you
> > > can invoke it with "-nw" and it will run in a terminal. Or you can
> > > install emacs-nox which does not drag in gtk/gdk/atk/etc, and it will
> > > only run in a terminal.
> > >
> > > So is your recommendation rename emacs to emacs-gnome, rename
> > > emacs-nox to emacs, and add a "-x" command line switch to emacs
> > > (renamed from emacs-nox) whose purpose is to emit an error message?
> > 
> > my recommendation is to find a way to consolidate the two distinct binaries 
> > into one that can optionally load gui libraries if A) they exist and B) an 
> > option was passed to load them.
> 
> The GUI libraries will be required by the dynamic linker in order to run 
> the binary if the GUI was enabled at compile time.  IOW, there are two 
> completely different binaries.  I would be nice if it worked the way you 
> describe, but I think it would be many man-years of work to implement all 
> the changes in emacs required.
> 
> > Or we just throw out the non-gui emacs and only ship the one that can do both, 
> > to be damned with pulling in a gtk stack.  I don't want conflicts and I don't 
> > want to involve alternatives if at all possible.
> 
> 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 :-)

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.  You've said it's because of rpmlint warnings but those
warnings aren't posted here or in the review [1]_.  Without being able
to see those, no one can help you and the reviewer evaluate whether
rpmlint is pointing out a valid concern, is being overly picky for this
package, or should be fixed in a way that we aren't even considering.

As always, rpmlint is a tool that helps reviewers pick out bad practices
but there can be cases where a bad practice in general is the best
practice for this case.  Reviewers and other packagers need specifics in
order to help you determine what to do.

[1]_: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225726

-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/ba9dfe0d/attachment.sig>