Hello!
I am running Slackware Linux 11.0 with kernel test26.s. In this forum I read some threads about package management and my impression is that like everything else in Slackware, it is best to handle package upgrade manually, instead of using automated tools like swaret, slapt-get or slackpkg. So, my question about manual package upgrade is as follows.
Sometimes the new version of a package requires newer versions of some dependencies, so to do the upgrade, one has to upgrade the respective dependencies as well. I wonder if there is some danger in doing so. My concern is that some other programs on the system might be incompatible with the newer versions of these dependencies, and they might stop functioning. If such a problem exists really, what procedure, if any, should be followed when doing package upgrade requiring multiple dependencies upgrade as well? If there is no such problem, i.e. if there is no danger of incompatibility between the newer versions of the shared libraries and some of the other programs on the system that use them, please let me know.

Thank you very much for your attention.
Regards,
Martin.

In practice, it is not really a problem if you are running a release version of Slackware, and only use reliability/security updates (in other words, use patches/). These usually imply very minimal changes.

Of course, if you run -current, you are on your own. You may have to recompile/upgrade software that is dependent on some upgraded library.

Everything that is in Slackware and patches, is coherent. For all the other stuff, use SlackBuilds .

I see. So if I try to upgrade a package that does not have a patch or a slackbuild, I run a risk. Actually that question arose when I tried to upgrade the xchat to its latest version. It required newer versions of some major libraries, which I did not feel confident to actually upgrade. And since neither these libraries, nor xchat still have neither patches nor slackbuilds, I have to stick to the older version of xchat to avoid problems.

Regards,
Martin

If you think about it ... why upgrade, unless it is a security issue ? I pondered this question a while (mostly while I was running FC4, FC5, and Ubuntu) ... I found that running the latest version of things is really a pain in the @$$ ! REALLY !!! How many times did something break when I upgraded something else ? Well, I can't count the times. So, from then I decided to:

1) Install Slackware (mostly because FC6 is insanely buggy)
2) Never upgrade anything, unless it is for security reasons.

I think it's a great plan ... except for those extenuating circumstances that do exist.

The questions you have to ask is, is it worth it. In my experience, xchat in Slack 11 works perfectly for its purpose, and Pat will issue a security update for it when necessary. If you install a newer version, you will have to maintain it yourself w.r.t. security issues.

BTW. The latest is not always the greatest. Pat often has a good reason for using a specific version that is in Slackware.

Ok, my impression so far is that the best way to handle system upgrade is to wait for new patches to appear in my local Slackware repository ( as I live in Bulgaria, it is http://mirrors.unixsol.org/slackware/slackware-11.0/)
and then just run "upgrade" to the packages in the "patches" directory. Am I right?

Yeah, spot-on. You could also mirror the patches directory through rsync if you have more than one Slackware machine. See also:

http://www.slackbasics.org/html/pkgmgmt.html#AEN2933

I know I'm "preaching to the choir" here with you, DdK, but others might get some benefit from this...
Think back to the the "dependency hell" you went through to manually compile some application that needed newer versions of some library, and that library needed a newer version of some other library, and three other things were linked against that library, so now they have to be recompiled. Since they're going to have to be rebuilt anyway, you decide to check out newer versions of those, and one of those requires a newer version of some other library, and the cycle repeats. Are we on the same page now?

Okay, now imagine how that must be for a *very* small group of people maintaining an entire linux distribution...

In essence, unless you *want* to walk that path (and it's okay if you do - being one of the first people down that path and finding/fixing the various bugs encountered is a great way to help Pat), it's best to stick with a stable release plus /patches/* and wait for the next stable release to upgrade. That way, all of the dependency issues have been worked out and documented in the ChangeLog, Release Notes, and other such files...

RW

I would like to ask you about using the local slackware mirror, which in my case is http://mirrors.unixsol.org/slackware/slackware-11.0/
There I should look for new versions of packages. I do not understand the designation of the different folders there. I can see:
extra
pasture
patches
slackware

So I should look for new official relesases in "patches". What about pasture, extra, slackware? What are the other folders intended to serve for? Tha automatic utility slackpkg so long as I understand from browsing the forum, consecutively looks for new versions of packages in all these folders and if it finds a new version, in installs it. Since I prefer to do this manually, I am interested in where I should look for new versions. Besides, is there a danger of upgrading to new versions of some libraries and then facing the possibility of incompatibility of some programs with the new versions of these libraries? I think there should not be such possibility provided that the official local slackware mirror is used, but I still feel obliged to ASK.

Thank you for your attention.
Regards,
Martin

For a stable release version of Slackware, the place to look for updates will be the patches/ directory. This directory will contain security and reliability updates that are issued after the official release of that Slackware version. In a stable release, there should be no problems with library version changes, because any new packages in patches/ will be compiled against the release versions of everything else.

On occasion, new packages are added to the /extra directory after the official release (for example, Pat put Firefox-2.0.0.1 into patches/ on Sat Dec 23 16:38:26 CST 2006).

The pasture/ directory should almost always be ignored (I would say *always* but I'm sure someone has an obscure exception case) - this directory contains packages that are either obsolete or otherwise on their way out, but Pat elected to leave them around for a while just in case.

Since you mention slackpkg, have a look at slackpkg.conf(5) (the man page) - notice the {FIRST,SECOND,THIRD,FOURTH} priority of the various directories about which you inquired.

RW

Thank you very much indeed. That is exactly what I wanted to know . I do not intend to use slackpkg, because so long as I understand from the discussions in the forum, it is best to do things manually with Slack