Hi all

The script that I wrote (with a lot of help from the LQ crew) has worked exceptionally well. It is fast (download speed being the limiting factor), secure (it checks md5sums and GPG signatures), and fails in a sane way if something goes wrong.

It requires the user to be logged in as root, and works best when the user:

1. Has a full installation of Slackware.
2. Is running the -stable branch of Slackware.
3. Has a directory set up on the hard drive for a persistent local mirror.
4. Has a proper GPG personal key and has imported and signed the Slackware Security GPG key.
5. Has not replaced packages from the default installation of Slackware with ones not maintained by the Slackware team.

The above list describes my installation pretty well. In the three and a half years that I've been running Slackware, starting with Slackware 11 in late 2006, I've only ever run a full installation of the stock -stable branch. I've added packages to Slackware that aren't included, but I've never replaced any until I decided to use the updated KDE 4.3.1 packages from Vincent Batts instead of the stock KDE 4.2.4 that comes with Slackware 13.

This last point is important for me because the Slackware developers released a a new patch for the kdebase-workspace-4.2.4 package today. So if I just run my script, I'll end up (most likely) breaking KDE! That's not a good thing.

The simple solution is to modify the lftp command in the script to exclude KDE patches, like so:

One caveat: I need to test that command to make sure it does what I want it to do,

The larger issue, though, is the fact that so much of this script is hard-coded. The mirror location is hard coded, and with it, the Slackware version. Now I'm going to hard-code the blacklist. When I upgrade to the next version of Slackware, I'll need to update the script with new values.

Personally, I'm not bothered by this state of affairs. This is, after all, a script and not a true application (like slackpkg ). To make this script more generally useful, I would need to set up variables for the mirror, Slackware version, and blacklist -- all passed to the lftp line of the script. The variables would probably need to be stored in an update_slackware.conf file that I would update from time to time, when needed.

Right now, there's two things stopping me from making the script more general:

1. I'm not sure how to pass variables to a command with Bash scripting.
2. Editing the script is as easy as editing a configuration file.

The first point is interesting because one of the major points of this exercise was to learn more about using Bash scripting to simplify the computer stuff that I do. So I'm probably going to continue hacking on this script as time permits and see if I can learn how to create and pass variables to it.

Mostly, though, my main future goals on this script are to improve the comments add a copyright, give credit to those who helped me and contributed code, better document the use assumptions, and add some disclaimers about causing problems with one's installation if one isn't careful.

I also want to refine the error-checking and provide more useful messages when something fails.

What if you upgrade a single package? Best to maintain a direct package blacklist I think. I know I have upgraded a few random packages here and there that are official. It would be nice to be informed of updates to these as well, in case you recompiled to add a feature, but then a new version is officially released (probably for security purposes) and your recompiled version is now vulnerable (and thus you should recompile the new version to include the compile-time feature you want). For example, I used to recompile Amarok to support MySQL. If you were not made aware of this (or if you don't study the ChangeLog like a hawk) you might be running an insecure program without knowing it.

slackpkg may be a more complex script but it is just that, a script.

Depends on what you mean by passing variables. You can pass variables to your script itself, or just pass variables to a command within your script. Variables are set with
and read with
So if you just want to pass options to a script, for example, the mirror location, you could use
Note that I believe that should work without fail in that instance with double quotes, but always be aware of quoting...single quotes would pass the literal $MIRROR.

Just have to source a configuration file that includes your variable settings for that.
or
would load all of the variables declared in settings.cfg.

Best to just go through a bash tutorial or browse other bash scripts and see what they're doing.

T3slider,

Thanks for the response! I definitely need to spend more time with a Bash tutorial or two. I get the concepts, but not the syntax.

I'm thinking that what would be really cool is for the script to list the updated packages and offer me a choice of installing all or just some of them. Year (and years) ago, I made pretty sophisticated batch files in DOS that had menus. Right now, though, with both a four-year-old son and a four-month-old son, my computer time is rather limited.

Regards,

I agree that a blacklist is essential, so I would recommend adding one (non-hard-coded). Take a look at my script (on the previous thread or on my site) for an easy way to add blacklist support.

H_TeXMeX_H,

I've definitely got a lot to learn. Your blacklist is an excellent idea and it's implemented elegantly.

I need to do something like that now because the MD5sum checking fails if the KDE package isn't there; thereby aborting the script. I really need to parse what you've done, but it looks like you use grep and cut to modify the CHECKSUMS.md5 file to remove the lines with the blacklisted packages.

Regards,