LinuxQuestions.org - 32-bit Packages and 64-Bit Packages with Included Multilib on One SlackBuild

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - 32-bit Packages and 64-Bit Packages with Included Multilib on One SlackBuild (https://www.linuxquestions.org/questions/slackware-14/32-bit-packages-and-64-bit-packages-with-included-multilib-on-one-slackbuild-867876/)

32-bit Packages and 64-Bit Packages with Included Multilib on One SlackBuild

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

Code:

APP=$PKGNAM

Code:

APP=<app's name>

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?

Quote:

Originally Posted by foodown (Post 4286585)

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?

Not a bad idea. A lot of other distribution mix it up. It's not a bad way to do it, just a different way.

One other draw back I see. If I decide to go back to 64-bit. Having integrated 32-bit, 64-bit packages would make that difficult.

AlienBOB's way maintains a separation of 32-bit, 64-bit. To go back to 64-bit only is a two step process.

slackpkg upgrade-all (gcc and glibc packages)
slackpkg clean-system -OR- removepkg /var/log/packages/*compat32*

Going back if needed is simple, especially using Sébastien Ballet's multilibpkg and compat32pkg