I was tinkering around with this, and thought somebody else out there might have some feedback for me.
I wrote this snippet of code to paste into (almost) any SlackBuild script, right before the call to makepkg at the end:
Code:
# If we've dropped in an ix86 package for multilib, and this is x86_64,
# then let's convert and include it.
if [ -r $CWD/$APP-$VERSION-i?86-$BUILD.t?z -a "$ARCH" = "x86_64" ]; then
OLD_CWD=$(pwd)
cd $CWD
OLD_PKG_NAME=$(echo $APP-$VERSION-i?86-$BUILD.t?z)
NEW_PKG_NAME=$APP-compat32-$VERSION-$ARCH-$BUILD.txz
/usr/sbin/convertpkg-compat32 -i $OLD_PKG_NAME -o $NEW_PKG_NAME -d $TMP
/sbin/installpkg --root $PKG $TMP/$NEW_PKG_NAME
cd $PKG
rm -r var/log/packages
cd $OLD_CWD
fi
Of course, sometimes, especially when rebuilding core Slackware packages, you have to add
or
at the beginning.
In any case, the result is that you can now run the SlackBuild on an x86, then copy the resulting package back into the source folder and run the same script again on an x86_64, and you get a package with multilib included native.
You have to have AlienBob's compat32-tools installed on the x86_64 system for it to work.
It takes more time doing it this way when building the package. And, since AlienBob already releases all of the core components of the distribution in multilib form, there's generally no reason to rebuild core packages in this way. With add-ons, however, I see no reason why this shouldn't be the norm for anything with shared objects included in it.
Maybe it already is the norm in some groups, and I'm dumb.
Perhaps more likely, I'm dumb because there is some reason that this is a bad way to do things.
The only real hang-up I can see is that people with "vanil" Slackware 64-bit systems who install a multilib-enabled package could wind up with unused 32-bit binaries on their system. I'm not sure that this is a big deal in this day and age ... Heck, I have KDE 4 sitting around on my system, and constantly being updated, and it never really gets used, and that doesn't bother me ...
What do you think?
