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/)

brobr 03-27-2020 09:09 AM

How can removepkg be triggered to remove stuff placed by a doinst.sh?
 
I ran in the same problem as described in this link
execute-script-after-removepkg-in-slackware.

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?

tadgy 03-27-2020 12:30 PM

Quote:

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

volkerdi 03-27-2020 02:19 PM

Quote:

Originally Posted by tadgy (Post 6105014)
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.

ehartman 03-27-2020 02:23 PM

Quote:

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

tadgy 03-27-2020 03:46 PM

Quote:

Originally Posted by volkerdi (Post 6105057)
Might as well not have *.new files then - you'd end up with all your config files replaced whenever you used upgradepkg.

I said it was a wish, not something that could be easily implemented :)

tadgy 03-27-2020 03:48 PM

Quote:

Originally Posted by tadgy (Post 6105014)
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... :)

volkerdi 03-27-2020 04:09 PM

Quote:

Originally Posted by tadgy (Post 6105087)
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.

brobr 03-27-2020 05:03 PM

Quote:

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?

bifferos 03-27-2020 05:36 PM

Quote:

Originally Posted by tadgy (Post 6105087)
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.

Didier Spaier 03-31-2020 06:37 AM

Quote:

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.

brobr 03-31-2020 11:30 AM

Yes, Thanks Pat, noticed this this morning ;-)

bormant 03-31-2020 11:43 AM

Quote:

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 03-31-2020 12:55 PM

Quote:

Originally Posted by bormant (Post 6106305)
@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.

tadgy 03-31-2020 02:46 PM

Quote:

Originally Posted by brobr (Post 6106302)
Yes, Thanks Pat, noticed this this morning ;-)

Seconded!

Really appreciated, Pat :)

volkerdi 03-31-2020 07:04 PM

Quote:

Originally Posted by volkerdi (Post 6106316)
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.

Sorry! :)


All times are GMT -5. The time now is 03:58 PM.