[Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent
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
> name-version-x86_64-build or name-version-i486-build or
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.
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:
> ). 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.
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