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

[Jude DaShiell]

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?


--
 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, Alessandro Baggi wrote:
>
> > I noticed that sometime a slackbuild requires to create user and group. In
> > my case, postgresql.SlackBuild requires user and group creation before
> > builing the software. Why don't put the user creation inside doinst.sh? The
> > user/group creation seems not needed for building purpose. I'm missing
> > something?
>
> At least some of the time, the user & group are required at build
> time. Sometimes this could be avoided (e.g. SlackBuild does a "chown
> user:group", could be done in doinst.sh instead), other times it's
> because "make install" does the chown (or "install -o user -g group")
> and will fail if the user doesn't exist.
>
> Also, we consider user & group creation to be something that shouldn't
> be automated.
>
> > /var/lib/pkg‐tools/douninst.sh/foo-1.0-noarch-1"
> >
> > This seems an interesting feature but I see it is not generally used or at
> > least I have not found a package that provides douninst.sh.
> >
> > Why is it not used?
>
> This feature didn't exist in Slackware stable until 15.0, so it's
> still relatively new. We have a lot of builds that would benefit
> from using it: *anything* that does "update-desktop-database" in
> the doinst.sh should do the same in douninst.sh. Also anything that
> installs info pages in /usr/info, or fonts in /usr/share/fonts.
>
> We have a few builds that do use it. Examples: take a look at
> audio/asap, audio/eawpats, system/vice, system/univga-font.
>
> If you've cloned the git tree, you can do something like:
>
>   git ls-files '*/*/douninst.sh'
>
> Also, there are a few that install the doinst.sh as douininst.sh too
> (because the same actions need to be taken, e.g. rebuilding the font
> cache or /usr/info/dir).
>
> > For example, removing postgresql it could be useful to remove user/group for
> > postgres or other files.
>
> Remember that upgrading a package actually involves removing
> it. Whatever the douninst.sh script does, will happen not just for
> "removepkg blah" but also for reinstalls, including upgrades. And the
> douninst.sh script doesn't know which action (remove or reinstall) is
> calling it.
>
> postgresql's actual databases are owned by the postgresql user. What
> should happen to them, if the douninst.sh removed the user?
>
> If you delete them, you *royally* screw things up for anyone who's
> just trying to upgrade postgresql to the latest version. People
> *don't* expect that upgrading their database engine will wipe out all
> its data!
>
> If you don't delete them, you end up with files that belong to a
> nonexistent user, for people who really are removing postgresql and
> not upgrading it. This isn't really fatal, but it's what you might
> call "untidy". It would make more sense for postgresql's data files
> to still be listed as belonging to the postgresql user, which is what
> happens now.
>