[Slackbuilds-users] Slackbuilds: doinst.sh and douninst.sh

[B. Watson]

On Thu, 18 Jul 2024, Jude DaShiell wrote:

> I've had a question about slackware removal process ever since I first
> installed slackware so figure I best ask it here.
> Slackware removes each file one by one.  It's possible with several
> package files in one directory so long as that's all in that directory to
> do something like rm -f target /* or rm -fr target if there are
> directories below target to remove directories and contents and that
> usually happens faster.  Why wasn't this second approach taken with
> slackware?

This got kinda long & involved, hopefully it's helpful.

Multiple reasons. Keep in mind, "removal" doesn't just mean "removepkg
foo", it also happens when you upgrade a package. "upgradepkg"
is equivalent to removing the old package and installing the new
(actually it's more complex: install new package, *then* remove the
old, then reinstall the new).

When you upgrade or remove a package, have you ever seen the "<file>
was found in another package. Skipping." message? That's essential,
and requires checking each file before deleting it. If removepkg
didn't do this check, you wouldn't be able to upgrade "core" libraries
(the ones found in aaa_glibc-solibs and aaa_libraries) because
deleting the old library would likely break all the shell commands
that removepkg itself is using.

Also, removing (including upgrading) a package should never delete
any file except files that are part of the package. You wrote "so
long as that's all in that directory", but how can removepkg know,
up front, that someone hasn't created more files in that directory,
ahead of time? It would have to check whether it's safe to use "rm
-rf"... which would take away any speed advantage gained by using
it, and if it determines it's not safe, it would have to revert to
removing the files individually like it does now.

Examples:

1. If a package installs /etc/appname/appname.conf (config file), and
later we upgrade the package, "rm -rf /etc/appname" would remove the
config. You want upgrades to leave config files in place (and that's
why the doinst.sh template has the new_config() function). For that
matter, I might have several old config files there, called things
like /etc/appname/appname.conf.old or maybe separate *.conf.roaming
and *.conf.home (to be copied over the main config, depending on
my location)... those are *my* files, not part of any package, and
removing a package should not delete them.

2. If a package called "appname" installs files in /usr/lib64/appname/plugins/,
and another package called appname-extra-plugins installs more files
in the same dir, you don't want "rm -rf /usr/lib64/appname/plugins/"
to run when you upgrade the main appname package, because it'll blow
away files that are in another package (appname-extra-plugins). It
would be even worse if upgrading appname-extra-plugins ran the rm,
because that would blow away the plugins that shipped with the main
package.

For what it's worth, other distro package formats work (broadly
speaking) the same way: RPMs and debs don't use "rm -rf" either.