I'm several months into maintaining Slackware64_13.1-multi-lib and I have a few observations.
The basic premise for applying security (and other) updates to Slackware is as follows:
- Get your security update notice via e-mail and then read the changelog. (Reading the changelog is a great idea because not all Slackware updates are security updates).
- Download the relevant packages from the /patches directory of your Slackware version's mirror (e.g. <mirror URL>/pub/slackware/slackware64-13.1/patches/).
- Run upgradepkg *.txz on the packages you downloaded and you're done!
Slackpkg does this automatically. As an alternative to Slackpkg, I wrote a script that does the same thing
. My script works beautifully for Slackware 13.1 (32 bit) and for pure 64-bit Slackware64.
It doesn't completely work for multi-lib. The to enable multi-lib Slackware64, we need to use multi-lib versions of GCC and Glibc provided by Eric "AlienBOB" Hameleers
. If there's an update that affects GCC and/or Glibc, then multi-lib users need to update from AlienBOB's repository rather than from the official patches to avoid overwriting the multi-lib capable files with ones that aren't. From what I've read, Slackpkg has the same issue; the recommendation is to blacklist GCC and Glibc when using Slackpkg.
Well, we've had two updates to Glibc very recently, so I can no longer simply mirror the /patches directory and update everything in it.
The "blacklist" for my script is pretty easy: I edit the CHECKSUMS.md5 file to remove the entries for Glibc (right now I do it manually, but I'm going to try sed in the script: 'sed -e '/^*glibc*$/d' CHECKSUMS.md5'), and I add '-X glibc*' (without the quotes) to my lftp command to avoid downloading those files. Then the update works perfectly! Except . . .
. . . I haven't downloaded the updated Glibc files from Eric's server.
Right now I do that manually, but I think i can modify my script to use lftp or rsync with Eric's multi-lib directory to create a local mirror that I can automatically update the multi-lib Glibc and (if necessary) GCC. Now I'm good to go except . . .
. . . I still need to update those libraries that got security updates that are also included in the basic set of 32-bit compatibility libraries that get the compat32 treatment.
From what I can tell, there haven't been many updates to the 32-bit compatibility libraries. Since Slackware64_13.1 was released, I think
only libtiff, libpng, and the constantly updated seamonkey-solibs have needed to get the compat32 treatment. The procedure here is to download the affected files from a 32-bit repository's /patches directory and then run Eric's convertpkg-compat32 script on those libraries.
Again, I think I can add that bit to my script by adding '-I *lib*' (without the quotes) to my lftp command to get the updated libraries from the proper repository, run the convertpkg-compat32 script, and then run upgradepkg on them. Right now, though, I do this step manually as well.
A Slacker on this board posted a link to a tool he created that is supposed to automate the compat32 part of this process
. I haven't tested it yet, but the feedback a few months ago seemed positive.
So there you have it: keeping multi-lib Slackware64 up-to-date in a bunch of easy steps.
Having lived with multi-lib for a while now, I'm of two minds about its maintenance needs. On one hand, being able to run 32-bit windows programs in Wine is very nice (that's the reason I installed the multi-lib files to begin with). On the other hand, it is more complicated to keep up-to-date with security fixes.
The procedure outlined above (get most patches from the regular patch source, get Glibc and GCC from Eric's server, then determine which 32-bit libraries have been updated give them the convertpkg-compat32 treatment) actually takes less time to do than to describe.
But it would be nice if there were a one-shop stop for all
multi-lib patches. But to do that would probably require maintaining three trees per version: 32-bit, pure 64-bit, and multi-lib 64-bit. That's probably a bit much to ask of Pat and the rest of the Slackware crew.