LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 03-27-2020, 09:09 AM   #1
brobr
Member
 
Registered: Oct 2003
Location: uk
Distribution: Slackware
Posts: 647

Rep: Reputation: 170Reputation: 170
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?
 
Old 03-27-2020, 12:30 PM   #2
tadgy
Member
 
Registered: May 2018
Location: UK
Distribution: Slackware (servers), Ubuntu LXDE (desktop/laptop)
Posts: 92

Rep: Reputation: 98
Quote:
Originally Posted by brobr View Post
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....
 
Old 03-27-2020, 02:19 PM   #3
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 1,898

Rep: Reputation: 6130Reputation: 6130Reputation: 6130Reputation: 6130Reputation: 6130Reputation: 6130Reputation: 6130Reputation: 6130Reputation: 6130Reputation: 6130Reputation: 6130
Quote:
Originally Posted by tadgy View Post
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.
 
2 members found this post helpful.
Old 03-27-2020, 02:23 PM   #4
ehartman
Senior Member
 
Registered: Jul 2007
Location: Delft, The Netherlands
Distribution: Slackware
Posts: 1,674

Rep: Reputation: 872Reputation: 872Reputation: 872Reputation: 872Reputation: 872Reputation: 872Reputation: 872
Quote:
Originally Posted by brobr View Post
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.
 
Old 03-27-2020, 03:46 PM   #5
tadgy
Member
 
Registered: May 2018
Location: UK
Distribution: Slackware (servers), Ubuntu LXDE (desktop/laptop)
Posts: 92

Rep: Reputation: 98
Quote:
Originally Posted by volkerdi View Post
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
 
Old 03-27-2020, 03:48 PM   #6
tadgy
Member
 
Registered: May 2018
Location: UK
Distribution: Slackware (servers), Ubuntu LXDE (desktop/laptop)
Posts: 92

Rep: Reputation: 98
Quote:
Originally Posted by tadgy View Post
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...
 
Old 03-27-2020, 04:09 PM   #7
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 1,898

Rep: Reputation: 6130Reputation: 6130Reputation: 6130Reputation: 6130Reputation: 6130Reputation: 6130Reputation: 6130Reputation: 6130Reputation: 6130Reputation: 6130Reputation: 6130
Quote:
Originally Posted by tadgy View Post
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.
 
1 members found this post helpful.
Old 03-27-2020, 05:03 PM   #8
brobr
Member
 
Registered: Oct 2003
Location: uk
Distribution: Slackware
Posts: 647

Original Poster
Rep: Reputation: 170Reputation: 170
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?

Last edited by brobr; 03-27-2020 at 05:05 PM.
 
Old 03-27-2020, 05:36 PM   #9
bifferos
Member
 
Registered: Jul 2009
Posts: 345

Rep: Reputation: 124Reputation: 124
Quote:
Originally Posted by tadgy View Post
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.
 
1 members found this post helpful.
Old 03-31-2020, 06:37 AM   #10
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2.1.2 on Lenovo Thinkpad W520
Posts: 9,370

Rep: Reputation: Disabled
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.
 
1 members found this post helpful.
Old 03-31-2020, 11:30 AM   #11
brobr
Member
 
Registered: Oct 2003
Location: uk
Distribution: Slackware
Posts: 647

Original Poster
Rep: Reputation: 170Reputation: 170
Yes, Thanks Pat, noticed this this morning ;-)
 
Old 03-31-2020, 11:43 AM   #12
bormant
Member
 
Registered: Jan 2008
Posts: 380

Rep: Reputation: 211Reputation: 211Reputation: 211
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
 
1 members found this post helpful.
Old 03-31-2020, 12:55 PM   #13
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 1,898

Rep: Reputation: 6130Reputation: 6130Reputation: 6130Reputation: 6130Reputation: 6130Reputation: 6130Reputation: 6130Reputation: 6130Reputation: 6130Reputation: 6130Reputation: 6130
Quote:
Originally Posted by bormant View Post
@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.
 
3 members found this post helpful.
Old 03-31-2020, 02:46 PM   #14
tadgy
Member
 
Registered: May 2018
Location: UK
Distribution: Slackware (servers), Ubuntu LXDE (desktop/laptop)
Posts: 92

Rep: Reputation: 98
Quote:
Originally Posted by brobr View Post
Yes, Thanks Pat, noticed this this morning ;-)
Seconded!

Really appreciated, Pat
 
Old 03-31-2020, 07:04 PM   #15
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 1,898

Rep: Reputation: 6130Reputation: 6130Reputation: 6130Reputation: 6130Reputation: 6130Reputation: 6130Reputation: 6130Reputation: 6130Reputation: 6130Reputation: 6130Reputation: 6130
Quote:
Originally Posted by volkerdi View Post
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!
 
1 members found this post helpful.
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
remove/cover a non-responsive area, triggered by buttons. Using only an input-form? Pomerano Programming 1 04-11-2018 01:06 AM
[SOLVED] Is removepkg aware of files modified by doinst.sh? m1m Slackware 4 08-19-2014 10:35 AM
Removepkg pkgtools and removepkg tar problem.. pepe41695 Linux - Newbie 3 08-26-2013 04:11 AM
Removepkg didn't remove pkg vdemuth Slackware 1 04-30-2012 01:07 PM
--ROOT=/some/stuff removepkg myPackage.tgz Leaves the directory in Place.. Alexvader Slackware 4 12-23-2009 11:12 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 06:48 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration