Read the changelog to check for package removal

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

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.

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

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.

Originally Posted by GazL 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.

Originally Posted by hitest 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.

Originally Posted by GazL 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:

grep -a 'Removed.$' ChangeLog.txt | sed -e 's#^.*/##g' -e 's#:.*Removed.$##g' | \
tr '\n' ' ' > removeme

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...

Originally Posted by drgibbon Just curious, what would you like to see?

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.

Originally Posted by GazL 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.

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.

Originally Posted by GazL 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.

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:

rm -rf place; ln -sf destination place #SYMINSTALL

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.

Originally Posted by GazL 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.

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

Originally Posted by NonNonBa 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.