[Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent

Robby Workman rworkman at slackbuilds.org
Fri May 29 03:22:38 UTC 2009


On Thu, 28 May 2009 22:59:18 -0400
Dragon Wisard <dragonwisard at gmail.com> wrote:

> On Thu, May 28, 2009 at 10:40 PM, <xgizzmo at slackbuilds.org> wrote:
> 
> > On Thursday 28 May 2009 21:15:55 Grissiom wrote:
> > > >
> > > > IMHO, if a package uses */lib64 then it's an ARCH=x86_64
> > > > package.
> > > >
> > >
> >
> > This seems to be what Slackware does. I think the best thing to do
> > here is just to make sure we use ARCH=${ARCH:-noarch} and not hard
> > code it. That way if the package builder is building for x86_64
> > then they should be using ARCH=x86_64 ./some.SlackBuild and it will
> > have an x86_64 tag on the final package. So far all of the python
> > builds I have seen that use setup.py find the right python path
> > on their own, so the SlackBuild does not have to be changed in
> > any other way.
> >
> 
> I don't like the idea of defaulting to noarch if the package is
> incompatible with x86_64. If we're going to have separate packages,
> they should be clearly marked as such. Making one 'noarch' and one
> 'x86_64' is inconsistent. It's either 'noarch' or it isn't.


Yep, I agree - I was about to reply with the same, but instead, ++
here.  :-)

-RW
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20090528/f4bfbdde/attachment.asc>


More information about the SlackBuilds-users mailing list