You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!

Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.

If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.

Having a problem logging in? Please visit this page to clear all LQ-related cookies.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

(excepting of slackware-current), may we safely assume that it is always safe to download patches and then as root run the upgradepkg command on any and all of these packages. And to do so without looking at the changelog.

Of course we match the version of the patches with our Slackware version. And we also do integrity check of the downloads (md5sum, pgp, etc., sha_whatever).
--

I ask this of the release versions of Slackware because I think I caught myself trying to use slackware-current strategies on a release version of Slackware (current dictates that you look at the changelog before you do anything) since packages can be forever removed or changed name and "you cannot just do upgradepkg on current since it is not limited to that but there is much more in current."

I'm assuming that you have a system that you don't want to blow away and re-install...

There are 2 (at least) sides to this. Firstly, will the package install correctly on your system? In this case the answer is usually yes if the pre-requisite packages are installed - and if you check the Slackware changelog for any gotchas. I'd never assume it was safe to upgrade a package without checking it.

Secondly, has new functionality been introduced (or old functionality been removed) that breaks the applications you're running? The answer to this isn't always obvious and will require testing. For example the changed functionality of a package may mean that it no longer performs certain tasks. If you have another application that relies on those tasks, the package upgrade may have already worked, but your app is broken because of the changed functionality.

So... read the changelog, backup before upgrading and test after upgrading.

The best answer to your question is "maybe." In most cases, yes, you can probably get away with "blindly" upgrading /patches for a release.
However, there are occasionally new things added in /patches -- for example, 11.0/patches/ had a new mozilla-nss package added for gaim's SSL suppport to work properly and reliably. Lots of people upgraded the gaim package, but failed to add the new mozilla-nss, so the GTalk and Jabber protocols didn't work anymore. Then they went to #pidgin, and the Pidgin devs concluded that the Slackware package was broken, when in reality it was the user who was broken.