Read the changelog to check for package removal
 

Slackware64-current is in the midst of very active development. Packages are being upgraded and or added on an almost daily basis.
Sometimes Mr. Volkerding also removes packages; this is noted in the -current changelog.
For example:

To remove these packages using slackpkg run:

Unless you've been very diligent about keeping your blacklists up-to-date, clean-system will also remove third-party packages, which may not be what many people want.

Read the changelog to check for package removal
 

You safely can unselect those packages you wouldn't have blacklisted ;-)

You know, during years I never used that because I feared it would remove everything without prompt!

That's true, you'll want your blacklist up to date before running slackpkg clean-all (although it gives you the chance to de-select packages that you actually want). In general that's not too hard, e.g., the default commented line:will blacklist all SBo packages once uncommented. Other repos can be added in the same way.

...or if you're really paranoid about making a mistake:

no package selection:

Cool!

Oh, cool!

Is there somewhere where this is documented? Because I double-checked the man page and didn't see it.

Not doubting you that it's there and it works, just wondering where else I might be able to look for future reference.

man slackpkg.conf

Yes. But, only if you blindly hit enter after you run the command. You can de-select third party packages prior to removing the packages highlighted by #slackpkg clean-system.

for a good reason exist

/etc/slackpkg/blacklist

as example to no remove alien or compat32 ...can blacklist

# If want remove compat32 comment this two tags below
# Removing this , disable wine usage.
[0-9]+compat32
[0-9]+alien

If use slackbuilds , can add

[0-9]+SBo

and clean-system ,turns secure action for third party packages.

After all , clean-system , show you a menu first , with a list of remove packages list ...you can deselect if no want to remove someone.

And should your friend actually manage to hose things with "clean-system," a list of your removed packages is in /var/log/removed_packages. ls -I can exclude things that have been upgraded, kernel packages, and the like.

This thread keeps getting better. I didn't know about this directory. ls -al --ignore=*upgraded* does the trick. Thanks for posting this.

slackroll will tell you which packages that aren't available any more with the list-transient command.

Btw: 'onoff' and co are the slackpkg.conf manpage, not slackpkg.

Edit:
D'oh, nevermind, Chuck56 already said that.

Well, uhh...
Uh... in case you are going through the removed files 'manually', maybe by searching the changelog, using removepkg instead, well, there's a '--copy' switch that generates an 'exploded' (aka, not tied up on a txz file) backup of the package which you could then re-generate if needed.


Ahem...hopefully that's less of a wasted post now... (and the worst thing is, I wasn't even aware of that until y'all told me so... hahaa)

But, as slackpkg, it won't say when a local package depends of a removed package, will it?

My update scripts work in a similar way: driven by the availability, or lack thereof of individual package files, so removal of discontinued packages is handled as part of the normal update process.


Nothing outside of a fully functional dependency based package system will handle that situation, and even then, it's only reliable so long as the packager who created it doesn't miss listing a possible dependency (some of which may very well be optional and auto included during the configure run).

Slackware's long held philosophy seems to be that doing it right takes so much effort and attention to detail that attempting to do so on a large scale is simply a fool's errand.

Agreed. Slackware's lack of dependency resolution is a source of strength, not a deficit. I admire and appreciate our package management system.

Well, in all honesty, I could pick some faults with it, but lack of dependency management isn't one of them. :)

Just curious, what would you like to see?

I normally parse the changelog with the following:

And then run removepkg with the generated list over my installed packages. I am sure that it could be done better but this has worked solidly for me for some years now...

Well, pre and post install scripts would be nice. and a post removal script could help with clean-up.

'.new' as a suffix is a bit generic and can lead to false positives when dealing with .new files. Case in point: /usr/doc/groff-1.22.4/examples/mom/elvis_syntax.new. Better to use something like .slacknew

Using hypens in package names and as a delimiter makes it difficult when it comes to parsing package file names as you have to start at the end and parse in reverse order. CRUX fixes this by using package#version.pkg.tar.gz. They also include pkg in the filename. which I like as it helps differentiate the file as a package rather than any other gzipped tarball. I like what they do here.

I've never liked how symlinks get appended to the doinst.sh, and I really don't like how the symlink lines added to doinst.sh are parsed during removal. If symlinks have to be separated from the tarball then IMO it would be far more reliable to put them in their own file (install/symlinks) or some such.

I also dislike how some stuff has to be duplicated across multiple packages. The glibc stuff being a good example of that, and the whole checking for duplicated files at removal stuff is clunky and slow, but I accept that this is inherent to the design and we're stuck with it.


Having said all that, our package system does and has worked for a long time, so please don't see this as an attack on it, nor is it a request for any specific changes. That's not my intent here. The package system was designed 25 years ago and IMO it simply shows a little.

I don't use anything but Slackware, but I'd be surprised Arch, Fedora, etc. couldn't provide something functional.

Still, indeed Slackware (doesn't) deal with it elegantly. Though it relies on the release cycle, IMO. You don't really care to have dead weight if you know every 18-24 months you'll have the occasion to all cleanup. That's also why I worry a bit if the two last devel cycle durations are meant to become a new standard.

The symlinks have to be separated because they must be able to clobber anything where they are set, even a full directory. I've once suggested to Pat to use this kind of syntax:

Primarily in order to save the pushd/popd stuff which ties the pkgtools to bash (no more subshell here), but also to help parsing. Sadly the transition between the two patterns would be a bit... ugly.

Personally, I still dislike the second installpkg in upgradepkg. On a bit old machines upgrading packages like kernel-modules seems to take ages.

Yes, this is indubitably the major point. You can dislike all you want about it but, damn, it just works! :)

Yes. There are always things that suck about an OS. Slackware sucks less than other operating systems.
Grateful to be a Slacker. :)