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

[Jude DaShiell]

In this case shortcuts could result in system crash something systems with
multiple users on them would not appreciate.  Thanks for the explanation.


--
 Jude <jdashiel at panix dot com>
 "There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo.
 Please use in that order."
 Ed Howdershelt 1940.

On Thu, 18 Jul 2024, B. Watson wrote:

>
>
> 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.
> _______________________________________________
> SlackBuilds-users mailing list
> SlackBuilds-users at slackbuilds.org
> https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - https://slackbuilds.org/faq/
>
>
>