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

Eric Hameleers eha at sox.homeip.net
Fri May 29 12:05:24 UTC 2009


On Fri, 29 May 2009, [UTF-8] Dušan Stefanovi? wrote:

> 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
> slack64?
>
> name-version-x86_64-build or name-version-i486-build or
> name-version-i486-build_s64?

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.

> Long time ago slack packages had different name scheme than today (you
> can see it here:
> ftp://ftp.slackware.no/pub/linux/slackware/slackware-4.0/slakware/d1/
> ). 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.

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) 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

-- 
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


More information about the SlackBuilds-users mailing list