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

[B. Watson]

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.