[SOLVED] How can removepkg be triggered to remove stuff placed by a doinst.sh?

Luckily, none of my scripts on SBo will need the douninst.sh functionality (that I can see), and I imagine very few will actually need it, but it's nice to have the option rather than potentially leaving stale files/folders around the system that aren't tracked by the package manager.

I like the introduction of a douninst.sh functionality. It allows a package install to include functionality that can be cleanly removed when the package is removed. Consider the use case of a package that generates log file information. The package can add a logrotate script so the log file information will not grow without control. If the package is removed then the douninst.sh can remove stale logfiles. Rather than few needing it, I see many using it.

Originally Posted by NonNonBa And as many that think the same touching tracking dependencies.

True, but douninst.sh is quite a bit different than tracking dependencies. And really, this is only touching the surface. Some package managers have scripts to support pre-install, post-install, pre-uninstall, and post-uninstall.

Originally Posted by NonNonBa This option should then be added to upgradepkg and in any other tool calling the pkgtools.

This would be something that Pat would need to decide, but I can see the benefit in adding support for upgradepkg and slackpkg.

Originally Posted by brobr Ha, so you can call dkms during the package build so that it installs into the package before it is installed via pkgtools? I am going to test that, thanks !-)

Hopefully it still works fine. I was toying with that back in 2016 and 2017 but ultimately removed support for it in the script (and then I stopped providing updates for the script).

Originally Posted by brobr One thing I do not completely understand: How would this work when -as is the case for the digimend-drivers- the dkms.conf is removed with the source by pkgtools before the douninst.sh is run?

This is a good point and I didn't think about that. To use dkms, it would need to be done in a pre-uninstall script, which is not supported or you'd have to do something funky to make sure the dkms.conf wasn't removed (I wouldn't recommend this). I suppose the alternative would be to just manually remove the modules using a wildcard for the kernel version.

rm -rf /lib/modules/*/location/to/modules.ko

Originally Posted by bassmadrigal I'm not going to continue this debate. It has been determined with a lot of different distro's package managers that a post-uninstall script is a good idea. Slackware has now implemented it and it is up to the package maintainers to use it in a sane manner. If someone is able to convince Pat to remove the douninst support, I doubt it will bother me, but it doesn't bother me that it's included either. I imagine as SlackBuilds are developed that start containing douninst scripts, the SBo admins will be making sure they are unlikely to cause harm to the system. For users who don't want to leave their system in the package maintainer's hands, they can simply create an alias like the following: alias removepkg='removepkg --skip-douninst' Then if they need to override that sometime, they'd just call removepkg with the absolute path /sbin/removepkg

Or just

\removepkg

Originally Posted by Richard Cranium Or just \removepkg

I didn't know that. Thanks!

@bassmadrigal: Thanks again for the suggestion and example how dkms can be directed to build kernel modules into the package. I adapted my Slackbuild to have this as an option. It's very nice to see quickly what dkms does (provided the script covers/reproduces all its steps). With this in mind, the package can work without a douninst,sh. Another thing, though, is that one needs to be aware to call dkms to remove modules from a running kernel (after an upgrade) BEFORE removepkg. As it needs a dkms.conf file for this (see above).

A way around this is to place a copy of the dkms.conf somewhere outwith the files and folders controlled by pkgtools. This can be done from the doinst.sh by means of a simple copy command. Then, a douninst.sh can
a) first call dkms with this 'parked' conf (put in /etc/dkms) for guidance what driver to uninstall and -after completion -
b) can remove the conf-copy from /etc/dkms.

This works quite nicely, but means appreciation of a douninst.sh. Which defies the rationale not to call dkms during installation of the driver. So, as the default option, the Slackbuild is set to make full use of dkms by means of the doinsth.sh and a douninst.sh. And by doing so may better reflect what the developers of the drivers have in mind (they advice to use dkms for installation of their drivers).

You can check it here: digimend-drivers-dkms

cheers

Originally Posted by brobr Another thing, though, is that one needs to be aware to call dkms to remove modules from a running kernel (after an upgrade) BEFORE removepkg. As it needs a dkms.conf file for this (see above). A way around this is to place a copy of the dkms.conf somewhere outwith the files and folders controlled by pkgtools. This can be done from the doinst.sh by means of a simple copy command. Then, a douninst.sh can a) first call dkms with this 'parked' conf (put in /etc/dkms) for guidance what driver to uninstall and -after completion - b) can remove the conf-copy from /etc/dkms.

Thanks for this. I updated my system76-io-dkms SlackBuild (https://gitlab.com/ErichRitz/slackbu...tem76-io-dkms/) to call "dkms remove" from douninst.sh. Although my resulting scripts turned out much simpler:

doinst.sh:

VER=@MODULE_VERSION@
dkms install system76-io/$VER

# Copy a backup of dkms.conf for module removal by douninst.sh.
cp usr/src/system76-io-$VER/dkms.conf etc/dkms/system76-io-$VER.conf

douninst.sh:

VER=@MODULE_VERSION@
CONF=etc/dkms/system76-io-$VER.conf
if [ -r $CONF ]; then
    dkms remove system76-io/$VER --all -c $CONF
    rm $CONF
fi

(The SlackBuild replaces @MODULE_VERSION@ with the real version number.)