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:
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?
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
|All times are GMT -5. The time now is 07:48 PM.|