LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   How can removepkg be triggered to remove stuff placed by a doinst.sh? (https://www.linuxquestions.org/questions/slackware-14/how-can-removepkg-be-triggered-to-remove-stuff-placed-by-a-doinst-sh-4175672073/)

allend 04-08-2020 09:44 AM

Quote:

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.

bassmadrigal 04-08-2020 10:54 AM

Quote:

Originally Posted by NonNonBa (Post 6109049)
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.

Quote:

Originally Posted by NonNonBa (Post 6109049)
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.

Quote:

Originally Posted by brobr (Post 6109089)
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).

Quote:

Originally Posted by brobr (Post 6109089)
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.

Code:

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

Richard Cranium 04-09-2020 04:59 PM

Quote:

Originally Posted by bassmadrigal (Post 6108760)
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:

Code:

alias removepkg='removepkg --skip-douninst'
Then if they need to override that sometime, they'd just call removepkg with the absolute path

Code:

/sbin/removepkg

Or just
Code:

\removepkg

bassmadrigal 04-09-2020 05:09 PM

Quote:

Originally Posted by Richard Cranium (Post 6109716)
Or just
Code:

\removepkg

I didn't know that. Thanks!

brobr 04-09-2020 08:30 PM

@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


All times are GMT -5. The time now is 09:22 PM.