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

[Grissiom]

2009/5/29 Dušan Stefanović <stefanovic.dusan at gmail.com>

> 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?
>
> 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.
>
> regards,
> ds
>

Yes, although the naming scheme is not the mission of this thread but I
think it *may* provide a solution for this problem. Especially for the ones
that think Slackware64 is just a other *version* of slackware but not the
stoke slackware in x86_64 arch.

But this will bring an other problem. What if the both the files *and* the
directory structure are arch independent?(bash-completion as an example,
although it not in slackware64 now) It's also non-sense to have two names
with one package that exactly the same.

-- 
Cheers,
Grissiom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20090529/4fea95b3/attachment.htm>