Help answer threads with 0 replies.
Go Back > Blogs > The Slacker's Blog
User Name


This is a semi-random collection of posts on nearly all things Slackware and Linux-related -- at least as I see it.
Rate this Entry

Keeping multi-lib Slackware64 up-to-date. . .

Posted 11-05-2010 at 10:00 AM by Lufbery

Hi all,

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:
  1. 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).
  2. Download the relevant packages from the /patches directory of your Slackware version's mirror (e.g. <mirror URL>/pub/slackware/slackware64-13.1/patches/).
  3. 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, and I add '-X glibc*' (without the quotes) to my lftp command to avoid downloading those files. Then the update works perfectly! See the completed script at the bottom of this post. 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. The real trick will be automating it.

Here's my "blacklisted" script:

# This script creates a local mirror of the /patches/packages directory of a Slackware mirror.
# Be sure to choose the correct Slackware mirror for the installed Slackware version.
# Note: run this script as root from the local ./patches directory.

#Synchronize the local mirror with the remote mirror:
#Note: the Glibc packages are blacklisted because I'm using multi-lib versions.
echo "Synchronizing the local mirror with the remote mirror."
lftp -c "open ; mirror -e -n -X glibc* packages"

#Download the most recent CHECKSUMS.md5 file:
echo "Downloading the most recent CHECKSUMS.md5 file."
rm -f CHECKSUMS.md5
lftp -c "open ; get CHECKSUMS.md5"

#Strip the Glibc entries from the CHECKSUMS.md5 file:
sed -i '/^.*glibc.*$/d' CHECKSUMS.md5

#Check for MD5 checksum errors and exit if some are found.
echo "Checking for MD5 checksum errors."
if grep "\./packages/" CHECKSUMS.md5 | md5sum -c | grep -v OK$
   then echo "Script aborting. Try manually downloading the file(s) listed above"
   exit 1 

echo "No errors found; checking package signatures and updating packages."

#Check GPG signatures and upgrade Slackware with downloaded packages:
cd packages
for package in *.t?z.asc
  if gpg --verify "$package"
    upgradepkg ${package%.asc}
    echo "ERROR:  ${package%.asc} doesn't match signature file. Skipped!" 1>&2

#Find configuration files that need attention:
echo "Checking for new configuration files:"
find /etc -name "*.new"

echo "If running multi-lib Slackware64, don't forget to check for Glibc/GCC updates and"
echo " 32-bit packages that need to be converted to compat32 and updated."
Posted in Uncategorized
Views 5130 Comments 1
« Prev     Main     Next »
Total Comments 1


  1. Old Comment

    Good post. I have been manually doing the same things to keep my multilib Slackware13.1_64 updated, all the while thinking to myself that I need to write a script to automate it. I appreciate what you have done, and I will try it out. A sticking point in my thinking has been how to handle the 32-bit system files. I had about come to the conclusion that it would be more efficient for me to just download AlienBOB's converted "compat32" files rather than maintain a list and convert them, but it hasn't been clear to me whether or not he is maintaining 13.1 compat32 files since they haven't changed. I see that the "current" compat32 file list has been changing.

    Thanks again,
    Posted 12-10-2010 at 06:28 PM by DrWhyN0t DrWhyN0t is offline


All times are GMT -5. The time now is 03:12 AM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration