<div class="gmail_quote">On Fri, May 29, 2009 at 12:08, Chess Griffin <span dir="ltr"><<a href="mailto:chess@chessgriffin.com">chess@chessgriffin.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="h5">
</div>I am probably missing the finer points of this discussion, but it seems<br>
to me that the current system works just fine. User A on a 32 bit<br>
system who has not set ARCH as an environmental variable and builds a<br>
package from a 'noarch' SlackBuild script, will end up with a package<br>
with 'noarch' in the name and libraries in /usr/lib. That can be<br>
re-distributed between other 32 bit systems. OTOH, User B on a 64 bit<br>
sysem who has set ARCH as 'x86_64', either in the environment or<br>
passing it to the SlackBuild script, will end up with a package with<br>
'x86_64' in the name, with libraries in /usr/lib64 which can be<br>
redistributed between other 64 bit systems.<br>
</blockquote><div><br>Yes, but currently some packages build from SlackBuilds(mostly for python modules) will install thing into /usr/lib64 even have "noarch" tag.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The truly independent 'noarch' packages are those simple ones that<br>
simply build a single /usr/bin/ binary with make or that install icon<br>
sets or something.<br>
</blockquote><div> <br>Hmm, I think rworkman will agree with you.<br></div></div><br>-- <br>Cheers,<br>Grissiom<br>