<?xml version="1.0" encoding="iso-8859-1"?><!-- generator="b2evolution/2.4.5" -->
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:admin="http://webns.net/mvcb/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/">
	<channel>
		<title>Josh Saddler - Latest comments on in the works</title>
		<link>http://blogs.gentoo.org/nightmorph?disp=comments</link>
		<description></description>
		<language>en-US</language>
		<docs>http://backend.userland.com/rss</docs>
		<admin:generatorAgent rdf:resource="http://b2evolution.net/?v=2.4.5"/>
		<ttl>60</ttl>
				<item>
			<title>In response to: in the works</title>
			<pubDate>Sat, 25 Nov 2006 10:54:43 +0000</pubDate>
			<dc:creator>Josh Saddler [Member]</dc:creator>
			<guid isPermaLink="false">c18464@http://blogs.gentoo.org/</guid>
			<description>@Stuart:&lt;br /&gt;
&lt;br /&gt;
Thanks for the tip; I'll check out the NX stuff. Wrapper scripts seem like more of a pain than any other solution, but I'll investigate everything I come across.&lt;br /&gt;
&lt;br /&gt;
In this case though, since it is a purely binary distribution, it should be placed in /opt/. This greatly simplifies things for both x86 and amd64; no need to specify installdirs based on arch.&lt;br /&gt;
&lt;br /&gt;
And it works fine, just fine, especially if I drop the proper stuff in /opt and call it with LD_LIBRARY_PATH=&quot;/opt/foo&quot; command.sh; it properly picks up the stuff. Actually, regarding /usr/appname, the weird thing is that in the RPM, it specifies files in /usr/bin/, /usr/share/, /usr/lib/, &lt;em&gt;and&lt;/em&gt; /usr/appname/. The executables are located in &lt;em&gt;both&lt;/em&gt; /usr/bin/ and /usr/appname/. It's seriously messed up; should just be /usr/lib/ and /usr/bin/, with the license/documentation in /usr/share/. That is, if it behaved properly. It needs to all go in /opt/ anyway.&lt;br /&gt;
&lt;br /&gt;
Regarding the secrecy, well...maybe I just want to be the first one to offer it to the community. As soon as I can figure out a solution to the env/library loading/installdir issue, then I'll open a bug for it and provide some installation docs on my devspace. :)&lt;br /&gt;
&lt;br /&gt;
Because if none of this works out, then I don't want too many folks besides myself to have wasted their time on it. I figure that at the least, the time I spend learning about Portage and ebuilds and how to work around more complicated installation issues is time well spent, even if this particular project ends up failing.</description>
			<content:encoded><![CDATA[@Stuart:<br />
<br />
Thanks for the tip; I'll check out the NX stuff. Wrapper scripts seem like more of a pain than any other solution, but I'll investigate everything I come across.<br />
<br />
In this case though, since it is a purely binary distribution, it should be placed in /opt/. This greatly simplifies things for both x86 and amd64; no need to specify installdirs based on arch.<br />
<br />
And it works fine, just fine, especially if I drop the proper stuff in /opt and call it with LD_LIBRARY_PATH="/opt/foo" command.sh; it properly picks up the stuff. Actually, regarding /usr/appname, the weird thing is that in the RPM, it specifies files in /usr/bin/, /usr/share/, /usr/lib/, <em>and</em> /usr/appname/. The executables are located in <em>both</em> /usr/bin/ and /usr/appname/. It's seriously messed up; should just be /usr/lib/ and /usr/bin/, with the license/documentation in /usr/share/. That is, if it behaved properly. It needs to all go in /opt/ anyway.<br />
<br />
Regarding the secrecy, well...maybe I just want to be the first one to offer it to the community. As soon as I can figure out a solution to the env/library loading/installdir issue, then I'll open a bug for it and provide some installation docs on my devspace. :)<br />
<br />
Because if none of this works out, then I don't want too many folks besides myself to have wasted their time on it. I figure that at the least, the time I spend learning about Portage and ebuilds and how to work around more complicated installation issues is time well spent, even if this particular project ends up failing.]]></content:encoded>
			<link>http://blogs.gentoo.org/nightmorph/2006/11/25/in_the_works#c18464</link>
		</item>
				<item>
			<title>In response to: in the works</title>
			<pubDate>Sat, 25 Nov 2006 10:31:34 +0000</pubDate>
			<dc:creator>Stuart Herbert [Visitor]</dc:creator>
			<guid isPermaLink="false">c18463@http://blogs.gentoo.org/</guid>
			<description>LDPATH in /etc/env.d isn't always the right way to go.  A wrapper script is sometimes the easier option.  See any of the NX packages for an example of how that approach works.&lt;br /&gt;
&lt;br /&gt;
Don't consider the devmanual as the definitive word on where things go.  That simply isn't true.  Sometimes, the right thing to do is to put stuff where upstream expects it.  Users switching to Gentoo from other platforms appreciate it - because the app is where they expect it.&lt;br /&gt;
&lt;br /&gt;
I don't know the app (what's with all the secrecy?  That's not the Gentoo way!), but if it was me, I'd be most likely to get it working in /usr/&amp;lt;appname&amp;gt; first, before even considering moving it to /opt.  It's easier to move something that works than to try and get something working in the first place.&lt;br /&gt;
&lt;br /&gt;
Best regards,&lt;br /&gt;
Stu</description>
			<content:encoded><![CDATA[LDPATH in /etc/env.d isn't always the right way to go.  A wrapper script is sometimes the easier option.  See any of the NX packages for an example of how that approach works.<br />
<br />
Don't consider the devmanual as the definitive word on where things go.  That simply isn't true.  Sometimes, the right thing to do is to put stuff where upstream expects it.  Users switching to Gentoo from other platforms appreciate it - because the app is where they expect it.<br />
<br />
I don't know the app (what's with all the secrecy?  That's not the Gentoo way!), but if it was me, I'd be most likely to get it working in /usr/&lt;appname&gt; first, before even considering moving it to /opt.  It's easier to move something that works than to try and get something working in the first place.<br />
<br />
Best regards,<br />
Stu]]></content:encoded>
			<link>http://blogs.gentoo.org/nightmorph/2006/11/25/in_the_works#c18463</link>
		</item>
				<item>
			<title>In response to: in the works</title>
			<pubDate>Sat, 25 Nov 2006 10:03:34 +0000</pubDate>
			<dc:creator>Josh Saddler [Member]</dc:creator>
			<guid isPermaLink="false">c18462@http://blogs.gentoo.org/</guid>
			<description>@dberkholz:&lt;br /&gt;
ahh, thanks Donnie. now i have to learn more about how i can actually make it work with said LDPATH. :p&lt;br /&gt;
&lt;br /&gt;
yay for #gentoo-dev-help! and, of course, our wonderful devmanual. :)</description>
			<content:encoded><![CDATA[@dberkholz:<br />
ahh, thanks Donnie. now i have to learn more about how i can actually make it work with said LDPATH. :p<br />
<br />
yay for #gentoo-dev-help! and, of course, our wonderful devmanual. :)]]></content:encoded>
			<link>http://blogs.gentoo.org/nightmorph/2006/11/25/in_the_works#c18462</link>
		</item>
				<item>
			<title>In response to: in the works</title>
			<pubDate>Sat, 25 Nov 2006 08:03:28 +0000</pubDate>
			<dc:creator>Donnie Berkholz [Visitor]</dc:creator>
			<guid isPermaLink="false">c18461@http://blogs.gentoo.org/</guid>
			<description>LDPATH in /etc/env.d/ file.</description>
			<content:encoded><![CDATA[LDPATH in /etc/env.d/ file.]]></content:encoded>
			<link>http://blogs.gentoo.org/nightmorph/2006/11/25/in_the_works#c18461</link>
		</item>
			</channel>
</rss>
