On Fri, Aug 01, 2008 at 01:21:40PM -0700, Garrett D'Amore wrote:
> On a separate note, its unclear to me whether SUNWemacs-nox is a sound 
> approach for Solaris.
> 
> It presents potential difficulties, as there is no precedent (that I'm 
> aware of) for having the same binary program (/usr/bin/emacs) 
> distributed by different packages.  It potentially raises challenges for 
> patching, and other sustaining efforts, and I'm not entirely certain 
> that this has been thoroughly considered yet.

That's not what SUNWemacs-nox does though.  According to the materials
/usr/bin/emacs is a script that execs the emacs-x or emacs-nox according
to whether one the other or both are installed.

[OT preemtive comment re: exec overhead.  The cost of that exec,
incidentally, should be in the noise considering what all that emacs
supports.  A magic executable feature that allows us to implement simple
isaexec-like executable selection logic in kernel land without incurring
the full cost of an exec call would be nice should this extra exec
overhead someday become problematic.]

> Notably, SUNWemacs-nox would be a strict subset of functionality, and 
> its main (and perhaps only) benefit would be to reduce the size of the 
> installation image (e.g. for minimization environments) so that it is 
> not dependent on X11.

Or so as to never use emacs with X11 if you don't like that.  (An env.
var. seems more appropriate for that than pkg install decisions though.)

> Also notably, emacs runs fine in a tty without X11 running, even when 
> compiled with X11 support.
> 
> Since there is not yet any standard for minimizing Solaris -- at least 
> as distributed by Sun (and indeed Solaris is already rather large), can 
> I humbly suggest to the project team that they might want to consider 
> dropping this portion of the project.  Other distribution builders that 
> want to deliver a system without X11 will have a larger task ahead of 
> them anyway, and can easily repackage emacs to their own taste if so 
> desired.

Given that enabling minimization appears to be a goal of IPS I'd argue
that what the project team proposes is the correct approach.

> As an alternative, perhaps delivery of an emacs called 
> "/usr/bin/emacs-no-x11" or somesuch might be a reasonable way to avoid 

That's pretty much what the materials actually propose.

Nico
-- 

Reply via email to