[oi-dev] 2106 bring xemacs into userland

[Bayard Bell]

On Sat, Feb 11, 2012 at 2:39 PM, Josef 'Jeff' Sipek
<jeffpc at josefsipek.net>wrote:

> On Fri, Feb 10, 2012 at 07:25:03PM +0000, Bayard Bell wrote:
> > The packaging is slightly tricky because there are two further sets of
> lisp
> > packages to make xemacs properly useful. I've packaged them separately in
> > case people want a really minimal install but also provided metapackages
> > (editor/xemacs/xemacs-gnome-full, editor/xemacs/xemacs-x11-full, and
> > editor/xemacs/xemacs-nox11). There's a bit of overlap between emacs and
> > xemacs, so for the time being I've made the latter depend on the former.
> A
> > follow-on change would be to patch so that the shared executables have an
> > alternate name under xemacs and are called by those names from it (this
> is
> > what Debian appears to do).
> >
> > https://bitbucket.org/buffyg/oi-build/changeset/0f759efa96bd
>
> From a quick glance...
>
> 1) any reason you're not using the (shorter) Illumos CDDL header instead of
> the OSOL one?
>

See first response. Will fix.


> 2) I haven't paid much attention to oi-dev recently, but could mediated
> symlinks be used to sort out some of the executable names?  (I don't use
> emacs, so I don't really care. :) )
>

Pass. I'm interested in xemacs and not bothered about ctags/etags support
or the rest, at least for the time being. If the problem needs solving,
there are plenty of ways to skin that cat. Mediated symlinks are probably
better targeted at something like making emacs get you either xemacs or
gnu-emacs. Related binaries that are specific to a larger application  or
otherwise tightly coupled should probably use fixed names for helper
executables rather than mediated symlinks, so that you only need to change
one link and can still get correct behavior for the app/binary set to which
the mediated symlinks don't point.


> --
> I'm somewhere between geek and normal.
>                - Linus Torvalds
>

Or not very self-aware.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openindiana.org/pipermail/oi-dev/attachments/20120212/ef55af94/attachment-0005.html>