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

[Dušan Stefanović]

On Fri, May 29, 2009 at 14:05, Eric Hameleers <eha at sox.homeip.net> wrote:
> It's really quite simple. If you build a 32bit compatibility package for
> slackware64, on slackware64, you are still building with an ARCH set to
> "x86_64" and with the "-m32" option added to the gcc invocation (assuming
> you are running a slackware with 32bit compatibility layer added on top).
> This will generate 32bit binaries, but the final package name will still
> have "x86_64" in the ARCH section.
>
> See
> ftp://anorien.warwick.ac.uk/slamd64/slackware64-current/source/a-compat32/bzip2-compat32/bzip2-compat32.SlackBuild
> for an example of how Fred Emmott created the 32bit compatibility packages
> for Slackware64. Also note that he added "-compat32" to the package _name_
> so that the 32bit package can co-exist with the 64bit package.
>

Well, I see advantage with "-compat32", but why call a 32bit binary
x86_64? Similary, why call noarch package x86_64 just because
directory structure is differnt? On the other hand, at
ftp://anorien.warwick.ac.uk/slamd64/slackware64-current/slackware64/x-compat32/
there are packages like libXau-compat32-1.0.4-i486-1_slamd64.txz or
libXres-compat32-1.0.3-i486-1_slamd64.txz

Maybe I don't see the point, maybe 32bit binary that is build on
slackware64 (with multilib added on top) is not true 32bit anymore, is
this the case here?

> Absolutely not going to happen! This is just not doing any good at all.
> There is a reason why the  SlackBuilds at slackbuilds.org are categorized by
> Slackware release. If you want a SlackBuild for Slackware 12.2 you go
> looking in http://slackbuilds.org/slackbuilds/12.2/ - the SlackBuild itself
> should not concern itself with the Slackware version.
>
> I see this every so often, when people ask that we change our philosophy
> because some other party will benefit from it (notably 3rd party package
> repositories that are built from SBo scripts)

I was actualy thinking about "first" party, slackware itself (and
things that happen after release, patches directory).
But, I'm not going to argue about that, pkgtools are good enough right now.

> but we have repeatedly made
> clear that we care about the quality of the scripts and that they should
> produce good packages. We are validating the scripts against one single
> Slackware release and that release branch is where the tarball is going to
> end up in our repository.
> If you want to change the name of your final package, or even the package
> extension (and thereby the compression scheme), you are perfectly free to
> edit the SlackBuild you've downloaded from our repository.
>
> Eric
>

Well, if this was addressed to me, just to be clear, I don't use/care
about 3rd party package repositories, and my question/suggestion
doesn't have anything related with them.

> --
> Eric Hameleers
> Email: alien at slackware.com
> Jabber: alien at jabber.xs4all.nl
> Gpg fingerprint: F2CE 1B92 EE1F 2C0C E97E  581E 5E56 AAAF A75C BDA0

regrads,
ds