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

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

- - Keeping multi-lib Slackware64 up-to-date. . . (https://www.linuxquestions.org/questions/slackware-14/keeping-multi-lib-slackware64-up-to-date-841951/)

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

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:

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.

Comments? Thoughts?

Quote:

Originally Posted by Lufbery (Post 4147226)

...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.

Comments? Thoughts?

Since Slackware64 is pure 64-bit and will remain so, I see no reason why Pat and crew would have to deal with support for a multilib add-on.

On the other hand, I provide multilib versions of some (glibc and gcc) packages which are easy to track if you schedule a script to check for updates to my multilib ChangeLog: http://slackware.com/~alien/multilib/ChangeLog .

By blacklisting the glibc and gcc packages in slackpkg you will at least avoid an involuntary return to a pure 64-bit system when any of those gets updated in Slackware... but Slackware64 will not break if you replace your custom multilib versions with originals. The only thing you lose is the capability to run 32-bit programs. That is easily detected, at which time a simple upgrade to multilib versions is all it takes to fix this.

I am certain that it will be easy to come up with something like my rsync_slackware_patches.sh script to keep an eye on the multilib ChangeLog and download updates when needed.

The converted "-compat32" packages are a completely different story because they can be updated (or not) independently of any change in Slackware. The majority of Slackware libraries will not see many security fixes (packages like libpng, libjpg and seamonkey-solibs are notable exceptions).

There is currently no tool except perhaps slapt-get that is able to track multiple official and 3rd-party Slackware package repositories. So, it all boils down to you, the administrator, to keep track of where you obtained the packages you installed.

I think that a combination of slackpkg and compat32pkg would not be a bad thing to use.

Eric

Hi Eric!

Thanks for weighing in.

Multi-lib has a lot of benefits, and I really appreciate your work making multi-lib Slackware easy to install and use!

As I said above, the process of keeping it up-to-date is a little complicated, but it actually takes less time to do than to describe. The real challenge is going to be automating the process. I'll take a closer look at your rsync_slackware_patches.sh script. Thank you.

In the meantime, does anyone have any idea why my sed script to strip out the glibc entries in the /patches/CHECKSUMS.md5 file didn't work?

Here's the script again:

Code:

sed -e '/^*glibc*$/d' CHECKSUMS.md5

Regards,

Quote:

Originally Posted by Alien Bob (Post 4147256)

I think that a combination of slackpkg and compat32pkg would not be a bad thing to use.

Eric

I've been seeing the security updates recently, and that's the approach I was considering - update through slackpkg, then compat32pkg. Is this the way one should proceed?

I'll give the slackpkg/compat32pkg method a go tomorrow (when I haven't had as much to drink ;)), and report back on that method.

Any thoughts, before I proceed in the morning, are appreciated!

Thanks,
Scott

Quote:

Originally Posted by Lufbery (Post 4147459)

Hi Eric!
In the meantime, does anyone have any idea why my sed script to strip out the glibc entries in the /patches/CHECKSUMS.md5 file didn't work?

Here's the script again:

Code:

sed -e '/^*glibc*$/d' CHECKSUMS.md5

I think you mean

Code:

sed '/^.*glibc.*$/d' CHECKSUMS.md5

which, based on logic, can be shortened to

Code:

sed '/glibc/d' CHECKSUMS.md5

I just updated both my Slackware64-multilib and Slackware32 boxes. Lately I've been suspicious of automated tools. Silly old geezer that I am. The whole process of upgrading 2 systems, 1 with multilib, took about 2 hours or so.

1. rysnc patches for both and upgradepkg
1a. Help son with updating slackware64 on his new motherboard
2. grab and upgradepkg AlienBob's new multilib packages
2a. oops forgot initrd/lilo for the patched 64-bit kernel so do that and reboot.
3. visually scan my slackware64-13.1/patches/packages for any matches to the *-compat32 set
3a. wife asks me a question about something or other.
4. convert those after checking which ones since I had forgotten by now.
4a. damn...wife says dinner's ready
4b. watch TV...oops forgot to finish the upgrade....
5. check the *-compat32 packages and that other steps were done correctly
6. upgradepkg the new *-compat32 packages

Just 6 easy steps. I don't know how long it would take without the distractions as I don't live in that world.

....hmmmm...maybe I should set up some sort of automation.....maybe go back to slackpkg/compat32pkg. If its good enough for Alien Bob, its good enough for me.

T3slider,

Thanks for the response. It seems to work, but it doesn't overwrite the CHECKSUMS.md5 file; instead it outputs to the screen.

When I try:

Code:

sed '/^.*glibc.*$/d' CHECKSUMS.md5 > CHECKSUMS.md5

I get an empty CHECKSUMS.md5 file.

Maybe I need to try this again tomorrow after I've gotten more sleep.

Regards,

Quote:

Originally Posted by Lufbery (Post 4147555)

T3slider,

Thanks for the response. It seems to work, but it doesn't overwrite the CHECKSUMS.md5 file; instead it outputs to the screen.

When I try:

Code:

sed '/^.*glibc.*$/d' CHECKSUMS.md5 > CHECKSUMS.md5

I get an empty CHECKSUMS.md5 file.

Maybe I need to try this again tomorrow after I've gotten more sleep.

Regards,

You want the -i switch with sed (which edits the file in-place).

Code:

sed -i '/^.*glibc.*$/d' CHECKSUMS.md5

Quote:

Originally Posted by T3slider (Post 4147609)

You want the -i switch with sed (which edits the file in-place).

Code:

sed -i '/^.*glibc.*$/d' CHECKSUMS.md5

Brilliant! That works perfectly. Thank you.

Okay then, here's my update_slackware.sh script with the Glibc packages blacklisted.

Code:

#!/bin/bash

#update_slackware.sh

# 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 slackware.mirrors.tds.net/pub/slackware/slackware64-13.1/patches/ ; 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 slackware.mirrors.tds.net/pub/slackware/slackware64-13.1/patches/ ; 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 

fi



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

do

  if gpg --verify "$package"

  then  

    upgradepkg ${package%.asc}

  else

    echo "ERROR:  ${package%.asc} doesn't match signature file. Skipped!" 1>&2

  fi

done



#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."

It's a start. Over the next few days, I'll take a closer look at Eric's script and see about syncing with the multi-lib Glibc and GCC packages.

Regards,

I'll be testing this script on my machine in the morning and will report back

Hello slackers,

To complete compat32pkg I recently started to work on another tool (called multilibpkg) which is dedicated to the managing (install/update) of the 64-bit part of the multilib (ie the packages compat32-tools, gcc* and glibc*).

As I reused part of the code from compat32pkg, I think that I will be able to publish a first (beta) version within one (or two) week(s). You will shortly find more at http://multilibpkg.sourceforge.net/ and http://sourceforge.net/projects/multilibpkg/.

Moreover, I work also, but a bit less, on the next release of compat32pkg which will provide a simple menu-driven interface like in pkgtool.

cheers.

--
SeB

Quote:

Originally Posted by phenixia2003 (Post 4149114)

Hello slackers,

To complete compat32pkg I recently started to work on another tool (called multilibpkg) which is dedicated to the managing (install/update) of the 64-bit part of the multilib (ie the packages compat32-tools, gcc* and glibc*).

---snip---

Moreover, I work also, but a bit less, on the next release of compat32pkg which will provide a simple menu-driven interface like in pkgtool.

That's good news. I'll take a look soon. :)