[SOLVED] How can removepkg be triggered to remove stuff placed by a doinst.sh?
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
That is, say after installing a jupyter nbextension one has to run extra commands to get links etc. made that connect the installed program to the nbextension machinery. The extra commands can be run from the doinst.sh.
However, after removepkg of the installed package the stuff (links, folders etc) put in place by those extra commands from doinst.sh need to be removed as well. (The same holds for for path-extension scripts put in /etc/profile.d, that have to be manually removed after a package).
Is there a way (in the Slackbuild or doinst.sh) to get these extra bits added to the description of the installed pkg so that they can be cleaned out by removepkg?
However, after removepkg of the installed package the stuff (links, folders etc) put in place by those extra commands from doinst.sh need to be removed as well. (The same holds for for path-extension scripts put in /etc/profile.d, that have to be manually removed after a package).
Is there a way (in the Slackbuild or doinst.sh) to get these extra bits added to the description of the installed pkg so that they can be cleaned out by removepkg?
I have often suffered from the same problem - I don't like turds (my name for untracked files) on the filesystem, and often wished that removepkg would clean up the stuff doinst.sh renames from .new etc.
What packages (and removepkg itself) need is a 'douninst.sh' script that's executed after package removal.
It wouldn't be too hard to code it in to removepkg, but as to whether Pat would accept such a patch....
I have often suffered from the same problem - I don't like turds (my name for untracked files) on the filesystem, and often wished that removepkg would clean up the stuff doinst.sh renames from .new etc.
Might as well not have *.new files then - you'd end up with all your config files replaced whenever you used upgradepkg.
those extra commands from doinst.sh need to be removed as well.
Links, strictly created with the syntax, in doinst.sh
Quote:
( cd usr/sbin ; rm -rf in.proftpd )
( cd usr/sbin ; ln -sf proftpd in.proftpd )
(note the double cd commands and the enclosing within parentheseses) will be removed by removepkg.
Anything moved into place (or not) by a call to the config function will not as removepkg can never be sure if that file is the default one out of the install package or a modified one (config() only moves it over when the file wasn't there yet, so at a first installpkg, normally never after an updatepkg). When config() leaves a .new file, that one will be removed, though.
In principle removepkg will never remove files and/or directories that may have been modified by the administrator.
What packages (and removepkg itself) need is a 'douninst.sh' script that's executed after package removal.
It wouldn't be too hard to code it in to removepkg, but as to whether Pat would accept such a patch....
Is this something you'd like to see in Slackware, Pat?
If so, I'm sure some of us could come up with some workable patches...
Is this something you'd like to see in Slackware, Pat?
If so, I'm sure some of us could come up with some workable patches...
To be honest, not particularly. This is hardly the first time the idea has been suggested, and a few leftover config files don't really seem to cause much harm in my humble opinion.
In principle removepkg will never remove files and/or directories that may have been modified by the administrator.
Yes this makes perfect sense and the fact that .new files are kept being created/found after upgrading packages is great as these signal that things could have been changed. I am impressed with the way for example /etc/group and /etc/shadow always accommodate novelties apart from having .new files going along with these that flag this. Most of these, though, concern packages that need to be ok to make everything work. And with 'ls *.new' they are easily found.
But what about the less essential stuff, say that comes with third party packages that are installed with build.scripts like those from SBo (These things can accumulate quite quickly, getting beyond a few leftover config files)? In most cases when one removes these (not upgrade) one is also no longer interested in old config files (if so, one would make a back-up). Bits of these packages can thus be kept lying around if these are not part of the package description, like files in /etc/profile.d/ that end up there via a doinst.sh. These often do not have a nice 'new' flag attached to them that makes them quickly traceable...
Well, questions may not be new, nor so are some wishes. But novel solutions to old looking questions could be interesting. How would a mechanism look like that 'document' what is installed outwith the package. This 'document' (or 'douninst.sh') could then be the basis - when removing a package - for informing (the most riskless scenario) that some bits are still left behind (that then can easily be dealt with 'by hand') or (more risky) could lead to their removal as part of removepkg. As described by e.hartmann, for links, such a mechanism is in place; but could this be done with/for other stuff?
Is this something you'd like to see in Slackware, Pat?
I'd like to see this, for the simple reason that it's fiddly to bolt on. You either wrap the pkg tools, or hack them, neither are particularly nice. It doesn't mean Slackware core distro has to use the feature (and I'd honestly prefer that it didn't).
'Repackaging' Slackbuilds could benefit because it could be a third-party provided script that does the install and it may provide an uninstall option. Install may involve a kernel module compile which you don't want to bake into your package. It's part of what makes Slackware so flexible that the packaging system doesn't care what happens in doinst.sh and you can bend it any way you like but in missing a douninst.sh there feels like a bit of a gap.
Tue Mar 31 04:00:43 UTC 2020 a/pkgtools-15.0-noarch-31.txz: Rebuilt. removepkg: support an uninstall script. See removepkg(8).
In the new removepkg:
Quote:
# Tue Mar 31 03:06:25 UTC 2020
# Support an uninstall script to be executed when the package is removed.
# The script should be a standard sh script with the same name as the package
# (without the .txz or other extension), and should be installed in
# /var/lib/pkgtools/douninst.sh.
Tue Mar 31 04:00:43 UTC 2020
a/pkgtools-15.0-noarch-31.txz: Rebuilt.
removepkg: support an uninstall script. See removepkg(8).
Quote:
# Tue Mar 31 03:06:25 UTC 2020
# Support an uninstall script to be executed when the package is removed.
# The script should be a standard sh script with the same name as the package
# (without the .txz or other extension), and should be installed in
# /var/lib/pkgtools/douninst.sh.
@volkerdi
Will installpkg copy install/douninst.sh from package tree to $ADM_DIR/douninst.sh/$shortname as for install/doinst.sh:
Code:
if [ -r $ROOT/$INSTDIR/doinst.sh ]; then
cp $ROOT/$INSTDIR/doinst.sh $ADM_DIR/scripts/$shortname
@volkerdi
Will installpkg copy install/douninst.sh from package tree to $ADM_DIR/douninst.sh/$shortname as for install/doinst.sh:
Code:
if [ -r $ROOT/$INSTDIR/doinst.sh ]; then
cp $ROOT/$INSTDIR/doinst.sh $ADM_DIR/scripts/$shortname
No. It's up to the SlackBuild to put it in /var/lib/pkgtools/douninst.sh/ with the proper name, which (by the way) is not the $shortname. This isn't much increased burden for creating a SlackBuild, but makes it so that installpkg doesn't need any changes and the uninstall scripts are tracked by the existing package file database.
No. It's up to the SlackBuild to put it in /var/lib/pkgtools/douninst.sh/ with the proper name, which (by the way) is not the $shortname. This isn't much increased burden for creating a SlackBuild, but makes it so that installpkg doesn't need any changes and the uninstall scripts are tracked by the existing package file database.
I was wrong, it is the $shortname after all... I'd completely forgotten that it's not the shorter shortname.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.