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

Dušan Stefanović stefanovic.dusan at gmail.com
Fri May 29 10:14:05 UTC 2009

I'm not trying to hijack this thread, but there is another question
related to this discussion. What about i486 packages that are created
for slackware64?
slackware64 is multilib, so it is perfectly legal to do this. How
should I name package that has 32bit binary inside, but is created for

name-version-x86_64-build or name-version-i486-build or

Long time ago slack packages had different name scheme than today (you
can see it here:
). It was name.tgz, then after few releases it was changed to what we
know today name-version-arch-build. Pat already has problem with this
naming scheme, because it doesn't have slackware version (you can see
that at any slack mirror, just look at patches directory). I know that
it is for Pat to decide and not for as, but maybe it is time for
change. pkgtools are already changed for next release, so maybe it is
possible to add slackware version to naming scheme.


On Fri, May 29, 2009 at 06:08, Chess Griffin <chess at chessgriffin.com> wrote:
> On Thu, 28 May 2009 22:57:06 -0500
> Robby Workman <rworkman at slackbuilds.org> wrote:
>> On Thu, 28 May 2009 23:45:40 -0400
>> xgizzmo at slackbuilds.org wrote:
>> > On Thursday 28 May 2009 22:59:18 Dragon Wisard wrote:
>> > > 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.
>> > >
>> >
>> > Then for 32 bit if it in not noarch then what its it? its not i386
>> > or i486 or i585 or i686. I don't see this as a problem that needs
>> > solving. It is really no different than a package for slackware 11
>> > not working on slackware 12.2. The packages are Slackware version
>> > (64 bit being a different version) dependant not arch dependant. If
>> > the package builder prefers to call the package something else then
>> > they can. Most of the python builds are noarch there is no arch
>> > dependant code in them so they ARE noarch. The problem is caused by
>> > a different version of Slackware that uses a different python path.
>> And of course, that's a valid counterpoint.  I guess we (the admins)
>> will discuss this elsewhere and work out something :-)
>> -RW
> I am probably missing the finer points of this discussion, but it seems
> to me that the current system works just fine.  User A on a 32 bit
> system who has not set ARCH as an environmental variable and builds a
> package from a 'noarch' SlackBuild script, will end up with a package
> with 'noarch' in the name and libraries in /usr/lib.  That can be
> re-distributed between other 32 bit systems.  OTOH, User B on a 64 bit
> sysem who has set ARCH as 'x86_64', either in the environment or
> passing it to the SlackBuild script, will end up with a package with
> 'x86_64' in the name, with libraries in /usr/lib64 which can be
> redistributed between other 64 bit systems.
> The truly independent 'noarch' packages are those simple ones that
> simply build a single /usr/bin/ binary with make or that install icon
> sets or something.
> --
> Chess Griffin
> _______________________________________________
> SlackBuilds-users mailing list
> SlackBuilds-users at slackbuilds.org
> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - http://slackbuilds.org/faq/

More information about the SlackBuilds-users mailing list