That seems to mostly work. I un-check most of the packages in the list, but left checked the oldest version of some of the innocuous packages like seamonkey and firefox. Then I installed openssl and even a serious one for a domain controller: samba. Both worked. I found that you have to remove something, related or not, or slackpkg upgrade won't run.

Ran into one problem may you all can guide me through. I want to upgrade php. search gives me the following:

But doing `slackpkg upgrade php` gives me:

php did not upgrade and is still at version 5.4.30. Doing install gives:

What does this mean?

That all mostly worked. I tested by removing a few innocuous packages like seamonkey and firefox when doing `slackpkg upgrade`. Then upgraded serious ones like samba and openssl. They worked. Note that if there are packages listed in the "(B)lacklist, (R)emove or (I)gnore" list, at least one has to be removed or the update will not go, even though the updated package has nothing to do with the package removed.

Making progress figuring out slackpkg.

So, if I now run `slackpkg upgrade-all` it should just work, right?

Will upgrade-all actually upgrade to a new release when it comes out? E.g. Slackware 14.2?

http://docs.slackware.com/howtos:sla...:systemupgrade

You can also follow the "legacy" (but working) method that will be described at the root of the installation media for Slackware-next in the file UPGRADE.TXT

I don't know if this would be helpful or not, as I have not tried it.

You can run:

This will update package lists, clean out obsolete packages automatically, install all new packages, and upgrade all existing packages.

By cleaning out obsolete packages with slackpkg, you save yourself some trouble by doing it on a case by case basis.

This may not work though if you have the new package and the old package installed side by side. I've never tried this, but it might be worth a shot to save time.

Or you could just back up your system and reinstall it using a fresh 14.1 installation media.

@marlk3: basically that will work, but there are some caveats and additional steps that the OP (and anyone in the same situation) needs to take. That's why I highly recommend everyone in concern to carefully read the article I mentioned in my previous post before proceeding.

Yes I agree. It was only a suggestion to save the OP time. Then of course if it fails, just do a fresh installation.

I have upgraded only manually using "upgradepkg --install-new" using a locally mounted ISO image from 14.1 to -current on two different laptops. I probably wouldn't trust slackpkg to upgrade a full release since I am a bit of a control freak when it comes to my OS. Though I don't doubt that slackpkg upgrades do work. I've just seen many many botched upgrades due to package manager errors/inconsistencies in other distributions.

Also, to the OP: Be sure to do a system backup before upgrading your system. Not issuing a backup prior to upgrades is always a big risk.

Save time? Hmm... Yes, but this reminds me the saying: "those who don't have enough time to do it right always have enough time to redo it".

Not sure of my translation though. In French: "On n'a jamais le temps de bien faire mais toujours le temps de recommencer".

1 members found this post helpful.

It seems the OP is having some trouble fully understanding slackpkg, how it functions and how to properly use it to keep a system up to date, for security fixes as a minimum. Didier the article you provided is excellent for system upgrades. Additionally I'd recommend:
http://www.slackpkg.org/
and
http://docs.slackware.com/slackware:slackpkg?s[]=slackpkg
Alien Bob also has a great explanation on combining slackpkg+ for access to unofficial repositories while also accessing the official repository mirrors, thus getting official patches for official packages but also those non-official packages upgrades (like multlib and ktown). http://alien.slackbook.org/blog/intr...-repositories/

I've used slackpkg for about 18 months and have used it for a system upgrade from 14.0 to 14.1 with success. However, I've also run in to problems having my slackpkg properly configured when used with slackpkg+. In both cases (upgrade and trouble with slackpkg+) it was due to a misconfigured blacklist! I'm hoping the OP has a properly configured /etc/slackpkg/blacklist (especially since kernel and gcc showed in his list of dups). I'm wondering if the OP should post his slackpkg.conf and blacklist just so we can check the config and give advice? Although it might well be because of misuse of installpkg when upgradepkg should have been used from direct input.

Let's not forget that slackpkg provides two good man pages, see man slackpkg and man slackpkg.conf.

About slackpkg+: I assume that it is preferable to be well acquainted with slackpkg before using it.

Similarly I think that it is preferable to be well acquainted with all the tools shipped in the pgktools package before using slackpkg. I don't say that for the OP as I am sure that mfoley knows these tools very well.

All useful information, thanks. Yes, I've saved the reference to Didier's link for the future. Going forward, I think my simplest solution (as confirmed by Didier's link) is to upgrade new Slackware releases using a fresh install. This, in fact, is what I've always done. What got me in trouble this time is, after installing from DVD, I ran the `slackpkg update; slackpkg upgrade-all` -- and where I went wrong was then restoring my backed up data and production files, which included /var/log (since I like to keep the logfiles until purged by logrotate), and /root (since I run production cron jobs from there and keep those jobs' logfiles). The problem is that slackpkg keeps stuff in /var/log and /root -- didn't realize that. So, configs related to my update/upgrade got clobbered; put back to the old releases' state, actually.

Other than that, I've done nothing special. I've not added anything to the blacklist and don't believe I've run anything other than `slackpkg update <package>`. I'll continue to do updates for individual packages and NOT do an update-all until the next release (cautions on kernel clobbers have scared me).

On more little idiosyncrasy I've come across when doing the Remove at the "(B)lacklist, (R)emove, or (I)gnore" prompt, If you remove a package it appears to attempt to restore any <config>.orig files back to <config>. I had to restore from backup my httpd.conf, httpd-ssl.conf, php.ini and ntp.conf files. Those .orig were generally ones *I* created when manually configuring, not ones created by slackpkg. From now on I'll name my saved config files <config>-org.

My remaining duplicate package list is:

Thanks for the caution about removing kernels. As you can see, I've got 6 in this list. I'll experiment with this.

Here's a bit of a concern. My /etc/lilo.conf has

# Linux bootable partition config begins
image = /boot/vmlinuz
root = /dev/md0
label = Linux
read-only

but there is no /boot/vmlinuz:

I've checked backups going back months and they are all the same as shown above, yet the computer reboots just fine. Oh well, topic for another thread?

Lastly, my blacklist has nothing in it except: aaa_elflibs. the blacklist file does have the following advice:

# Automated upgrade of kernel packages aren't a good idea (and you need to
# run "lilo" after upgrade). If you think the same, uncomment the lines
# below
#
#kernel-firmware
#kernel-generic
#kernel-generic-smp
#kernel-headers
#kernel-huge
#kernel-huge-smp
#kernel-modules
#kernel-modules-smp
#kernel-source

So, I should uncomment all these, right? That will remove the kernels from my "(B)lacklist, (R)emove, or (I)gnore" list, right?

Mark, I'm really confused what your process of upgrading packages is going to be? Are you planning to use slackpkg, or are you going to manually use upgradepkg when you see a new package available, and from which repository? I think it is imperative for you to decide on one method and not mix the two, or you'll continue to have an inaccurate /var/log.
If you are going to use slackpkg, then yes you should un-comment the kernel lines in the blacklist.
If you are going to use upgradepkg, then I'd advise not upgrading the kernel items unless doing a full upgrade according to Patrick's instructions in the readme's of the DVD.
Only use installpkg if you are installing a new package, not for upgrading.
My personal recommendation is that you start using slackpkg, importantly because if you set a cron to run weekly, you'll automatically get the security updates that you otherwise have to watch for from the security email list. (You have joined the security email list, Yes?) To properly use slackpkg, read the links previously provided and correct your blacklist (which should also have aaa-elflibs un-commented). To me this is the only reliable way to keep the standard Slackware installation (32 or 64 bit) up to date for security, patches, and newest official apps.

As far as using slackpkg, the command slackpkg update only updates the local repository of potential applications to install, it installs nothing. The slackpkg upgrade-all is what will look at your current packages and determine if a newer (not necessarily newer version) package is available. It will then removepkg the old package without removing the config, then install the new package, then compare the new config for the package with you old config and either replace or offer you the ability to edit, see the differences, or merge the files. Again understanding the slackpkg process from the links previously provided is important. But the advantages of slackpkg is that it gives you a simple, effective, least time consuming manner to keep your system updated.

Hope this all helps.

I've scanned previous postings and don't find that I ever said that I used the upgradepkg or installpkg commands. To the best of my knowledge, I've only ever used slackpkg. As I've said, I think the /var/log repositories got messed up because I restored a production backup and did not exclude /var/log/packages, etc.

OK, will do that.

So, you suggest the `slackpkg update; slackpkg install-new; slackpkg upgrade-all; slackpkg clean-system` sequence be run in a cron job, weekly? Hmm, how does a non-interactive cron running of "update" and "upgrade-all" handle the user interactive pieces? is slackpkg smart enough to figure that out? How does it handle the .new files? Should I change the POSTINST option in /etc/slackpkg/slackpkg.conf?

Well, no I haven't, but security is really my chief goal with this whole process. How do I do that? Is the "security email list" documented somewhere than I can read about what it does, how it works and how to join?

Yes, here. Just send an email to majordomo@slackware.com with "subscribe slackware-security" in the body of the email.

After that you will receive all the Slackware Security Advisories that are also archived there.

With a production system aiming to keep the currently installed version fully patched, you should only need the update (to find out what new patches are available) and upgrade-all (to actually upgrade those packages). Slackware doesn't introduce new packages or remove old ones once a stable build is released, so there'll only be patches to packages available for that version. install-all and clean-system are generally used when upgrading from one stable to another (14.0 to 14.1) or to upgrade to -current (and to keep -current upgraded, since those packages can and do change during the development process) to install the packages that have been introduced to the system and remove the packages that are obsolete. This just won't occur on a stable release.

Personally, I would never leave something like this automated. Within stable, the likelihood of a conf file needing changes is slim (but could happen if a default setting created a security risk), but I still wouldn't want to just let the system upgrade by itself on the off-chance something goes wrong. Especially if you're running a production server, where downtime is costly. In all actuality, if you're subscribed to the security email, you'll be notified when something is patched and then you can run slackpkg on your system. That is how I would do it.

However, if you do want to actually automate it for cron usage, you'd need to edit /etc/slackpkg/slackpkg.conf and turn "BATCH" mode on (towards the end of the file). I would also verify that DEFAULT_ANSWER and POSTINST are set the way you want them (the whole conf file is well commented so you should be able to figure them out).

mfoley, I apologize for suggesting you were using upgradepkg. My suggestion to run a cron job, was based on assuming you would know how to respond to interactive request, like responding to .new files. As bassmadrigal says, it would be best to manually update when you receive the security updates emails.

As for your trying to keep the var/log for other application setting, have you considered a cron job to only save everything, except the slackware packages?