On Fri, Mar 5, 2010 at 01:48, Ciaran McCreesh <span dir="ltr">&lt;<a href="mailto:ciaran.mccreesh@googlemail.com">ciaran.mccreesh@googlemail.com</a>&gt;</span> wrote:<br><div class="gmail_quote"><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 Thu, 4 Mar 2010 18:38:58 +1300<br>
Sess &lt;<a href="mailto:leycec@gmail.com">leycec@gmail.com</a>&gt; wrote:<br>
&gt; {*} Stable exheres. There aren&#39;t any. Most exheres are known<br>
&gt; unstable and marked as such, or otherwise known stable (...for most<br>
&gt; architectures for most distros) and still marked unstable.<br>
<br>
</div>The whole stable / unstable thing&#39;s a Gentooism that doesn&#39;t really<br>
work. When we reach a point where we consider stability to be<br>
interesting, we&#39;ll probably do something completely different.<br></blockquote><div><br>Who doesn&#39;t consider stability interesting? I do. (Not as much as, say, Debian developers. But I do.)<br><br>What&#39;s the issue with Gentoo&#39;s stable/unstable dichotomy? The core idea of marking known working exheres as &quot;stable&quot; and experimental exheres as &quot;unstable&quot; strikes me as fundamentally useful. Is there another way?<br>
<br></div><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">
&gt; {*} &quot;xorg-server&quot; not a hard dependency of X.org-dependent exheres.<br>
&gt; Not a single exheres pulled in &quot;xorg-server&quot;. Simply solved, of<br>
&gt; course: &quot;paludis -i xorg-server&quot;. Everything works now. (Am I missing<br>
&gt; something?)<br>
<br>
</div>You&#39;re missing that those packages don&#39;t require an X server. They just<br>
require a few X libraries. It&#39;s entirely reasonable to install X clients<br>
on a box that does not itself have an X server.<br><div class="im"></div></blockquote><div><br>Yes, of course. But is it reasonable to install a X windowing manager without an X server? (FVWM, in my case.)<br></div><div>
 </div><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">
&gt; {*} No &quot;nano&quot; installed by default. Now, I encapsulate myself in<br>
&gt; &quot;vim&quot; as much as the next geek. And I still find Exherbo&#39;s disclusion<br>
&gt; of &quot;nano&quot; a wee... inhospitable. I doubt including &quot;nano&quot; would<br>
&gt; inflate the staging archive much. This suggests religious reasons.<br>
&gt; Tell me I&#39;m wrong. :}<br>
<br>
</div>There&#39;s e4r, if you can&#39;t handle the POSIX standard text editor.<br><div class="im"></div></blockquote><div><br>It&#39;s not about what I can handle. I handle vim; I handle emacs; heck, I handle Eclipse.<br>
<br>It&#39;s about what the average user can handle. I wasn&#39;t aware of &quot;e4r&quot;. Looks respectable. Google and the e4r splash message suggest this is an Exherbo-specific patch. Perhaps Exherbo documentation should mention its existence. Installation instructions might be a helpful start...<br>
<br>Installation instructions on a Wiki would be a better start.<br> </div><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">
&gt; {!} No &quot;baselayout-2&quot; or &quot;openrc&quot; exheres.<br>
<br>
</div>Because baselayout-2 is approximately three zillion times more horrible<br>
than baselayout-1. If you like baselayout, use Gentoo.<br><div class="im"></div></blockquote><div><br>I like Gentoo. I like Exherbo more. That&#39;s why I&#39;m using it.<br> </div><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">
{*} No &quot;/usr/portage/profile/use.desc&quot; or<br>
&gt; &quot;/usr/portage/profile/use.local.desc&quot; equivalents that I could find.<br>
&gt; I prefer grepping files to grepping &quot;--show-use-descriptions&quot; output<br>
&gt; when maintaining &quot;/etc/paludis/options.conf&quot;.<br>
<br>
</div>Use &#39;cave show&#39; to get descriptions. Option descriptions mostly live in<br>
individual exhereses, not globally, although there is metadata/options/.<br><div class="im"></div></blockquote><div><br>Yes, of course. That&#39;s not what I&#39;m suggesting. I&#39;m suggesting some mechanism for grepping all uses of some or several options across all exheres: e.g., &quot;cave show --type option qt4&quot;.<br>
</div><div><br></div><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">
&gt; {*} MYOPTIONS syntax. It looks increasingly like a markup-based<br>
&gt; scripting language: e.g., &quot;[[ number-selected = exactly-one ]]&quot;.<br>
&gt; Reinventing the wheel, mayhap? This looks to be a programmatic<br>
&gt; problem. I can&#39;t help but feel a programmatic solution might be more<br>
&gt; appropriate.<br>
<br>
</div>Doing it as a function breaks the whole &#39;upfront configuration&#39; thing,<br>
and makes automated testing a pain in the arse. The syntax we have<br>
covers nearly every use case, and pkg_pretend is there for the rest.<br><div class="im"></div></blockquote><div><br>Fair enough, Ciaran. :)<br> </div><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">
&gt; Tangentially: why the &quot;MY&quot; prefix on &quot;MYOPTIONS&quot;?<br>
<br>
</div>Because it&#39;s a lot less likely to bugger up makefiles than OPTIONS.<br>
<div class="im"></div></blockquote><div><br>Sweet. Thanks. (Are we really exporting exheres-specific globals to Makefiles? I&#39;m surprised Makefiles aren&#39;t sandboxed, in some fashion.) <br><br></div><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">
&gt; {*} &quot;cave.&quot; I&#39;m not fond of the name... It&#39;s non-descriptive; it&#39;s<br>
&gt; non-expressive; it&#39;s non-unique. Paludis. Pacman. Apt-get. Great<br>
&gt; names. &quot;cave&quot;? I&#39;d like to know the design impetus behind this one.<br>
<br>
</div>It&#39;s Latin.<br><div class="im"></div></blockquote><div><br>It&#39;s also indistinguishable from a commonplace four-letter English word.<br></div><div> </div><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">
&gt; &quot;dhcpcd.&quot; The 5.x.x branch of &quot;dhcpcd&quot; is unstable and significantly<br>
&gt; breaks backward compatibility with the 4.x.x branch. For example:<br>
&gt; passing the &quot;-N&quot; option to dhcpcd 4.x.x prevents dhcpcd from<br>
&gt; overwriting &quot;/etc/ntp.conf&quot;; passing the same option to dhcpcd 5.x.x<br>
&gt; produces the (humorously misspelled) fatal error: dhcpcd: unknown<br>
&gt; otpion &#39;eth0&#39; Yes. Fatal error. And it doesn&#39;t even reference the<br>
&gt; offending option. Thanks, Roy Marple. On my 64-bit AMD machine,<br>
&gt; dhcpcd 5.x.x also tends to enter &quot;unkillable&quot; process states where<br>
&gt; not even &quot;kill -9&quot; is sufficient to kill a zombified dhcpcd process.<br>
&gt; I don&#39;t know what the proper Exherbo protocol is here, but marking<br>
&gt; the dhcpcd 4.x.x branch stable for all architectures would probably<br>
&gt; be a healthy start. Emitting a notice concerning backward<br>
&gt; incompatibility at installation time of the dhcpcd 5.x.x branch<br>
&gt; should probably also be helpful.<br>
<br>
</div>Bugs go upstream. If you don&#39;t like 5.x, mask it yourself and maintain<br>
4.x.<br><div class="im"></div></blockquote><div><br>I&#39;m not suggesting that I don&#39;t like 5.x. I&#39;m suggesting that 5.x significantly breaks backwards compatibility with 4.x. Thus, porting &quot;/etc/conf.d/net&quot; from dhcpcd 4.x to 5.x such that the system still works is non-trivial.<br>
<br></div><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">&gt; {*} &quot;inquisitio.&quot; Still orders of magnitude slower than Gentoo&#39;s &quot;eix.&quot;<br>

&gt; Ideas why?<br>
<br>
</div>Because it gives correct answers.<br></blockquote><div><br>I don&#39;t recall receiving incorrect answers from &quot;eix&quot;, but submit it may have happened. Once. Maybe twice. On the whole, I would happily pay for faster response times with imperceptibly reduced precision.<br>
 </div><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">
&gt; {*} Non-free firmware. My discrete Radeon HD4330 video<br>
&gt; card requires non-free firmware, freely available at:<br>
</div>&gt; <a href="http://people.freedesktop.org/%7Eagd5f/radeon_ucode/" target="_blank">http://people.freedesktop.org/~agd5f/radeon_ucode/</a>&lt;<a href="http://people.freedesktop.org/%7Eagd5f/radeon_ucode/" target="_blank">http://people.freedesktop.org/%7Eagd5f/radeon_ucode/</a>&gt;.<br>

<div class="im">&gt; I&#39;d like to see non-free firmware optionally available via some<br>
&gt; repository (if not conflicting with Exherbo policy) or otherwise<br>
&gt; discussed in Exherbo documentation.<br>
<br>
</div>You are welcome to put it in your own repository, and you can have your<br>
own repository listed in ::unavailable-unofficial.<br></blockquote><div><br>Sweet idea. Exherbo empowers. Thanks for the time, Ciaran; and take care.<br><br>Humbly yours,<br>Cecil<br></div></div>