I *think* I've got the right licensing bits in there now. I've got another change I'll send out shortly, 2121, to clean up the templates. If there's any need to iron this out, let's do it with that change.<br>
<br><a href="https://bitbucket.org/buffyg/oi-build-2106/compare/..buffyg/oi-build">https://bitbucket.org/buffyg/oi-build-2106/compare/..buffyg/oi-build</a><br><br><div class="gmail_quote">On Sun, Feb 12, 2012 at 8:49 PM, Bayard Bell <span dir="ltr"><<a href="mailto:buffer.g.overflow@gmail.com">buffer.g.overflow@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">On Sat, Feb 11, 2012 at 2:39 PM, Josef 'Jeff' Sipek <span dir="ltr"><<a href="mailto:jeffpc@josefsipek.net" target="_blank">jeffpc@josefsipek.net</a>></span> wrote:<br>
</div><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><div>On Fri, Feb 10, 2012 at 07:25:03PM +0000, Bayard Bell wrote:<br>
> The packaging is slightly tricky because there are two further sets of lisp<br>
> packages to make xemacs properly useful. I've packaged them separately in<br>
> case people want a really minimal install but also provided metapackages<br>
> (editor/xemacs/xemacs-gnome-full, editor/xemacs/xemacs-x11-full, and<br>
> editor/xemacs/xemacs-nox11). There's a bit of overlap between emacs and<br>
> xemacs, so for the time being I've made the latter depend on the former. A<br>
> follow-on change would be to patch so that the shared executables have an<br>
> alternate name under xemacs and are called by those names from it (this is<br>
> what Debian appears to do).<br>
><br>
> <a href="https://bitbucket.org/buffyg/oi-build/changeset/0f759efa96bd" target="_blank">https://bitbucket.org/buffyg/oi-build/changeset/0f759efa96bd</a><br>
<br>
</div></div>From a quick glance...<br>
<br>
1) any reason you're not using the (shorter) Illumos CDDL header instead of<br>
the OSOL one?<br></blockquote></div><div><br>See first response. Will fix.<br> </div><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

2) I haven't paid much attention to oi-dev recently, but could mediated<br>
symlinks be used to sort out some of the executable names?  (I don't use<br>
emacs, so I don't really care. :) )<br></blockquote></div><div><br>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.<br>

 </div><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span><font color="#888888">--<br>
I'm somewhere between geek and normal.<br>
                - Linus Torvalds</font></span><br></blockquote></div><div><font color="#888888"><br>Or not very self-aware.</font> </div></div>
</blockquote></div><br>