LinuxQuestions.org
Share your knowledge at the LQ Wiki.
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-31-2020, 10:44 PM   #16
gus3
Member
 
Registered: Jun 2014
Distribution: Slackware (x86 and ARM)
Posts: 335

Rep: Reputation: Disabled

Quote:
I'd completely forgotten that it's not the shorter shortname.
That sounds like a 21st century situation. Hopefully, it'll be resolved before the 2037 problem.
 
Old 03-31-2020, 10:48 PM   #17
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 1,910

Rep: Reputation: 6173Reputation: 6173Reputation: 6173Reputation: 6173Reputation: 6173Reputation: 6173Reputation: 6173Reputation: 6173Reputation: 6173Reputation: 6173Reputation: 6173
Quote:
Originally Posted by gus3 View Post
That sounds like a 21st century situation. Hopefully, it'll be resolved before the 2037 problem.
2038. We have an off-by-one error.
 
Old 04-01-2020, 01:45 AM   #18
bormant
Member
 
Registered: Jan 2008
Posts: 380

Rep: Reputation: 211Reputation: 211Reputation: 211
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
So if anyone rename package file for any reason she breaks this feature. Until now there was only cosmetic "breakage" for this scenario -- lost description from slack-desc and only if shorter shortname is changed.

Another possible scenario for installpkg:
The "half consistent" way for install/douninst.sh is
1) copy it (in installpkg) to /var/lib/pkgtools/douninst.sh/$shortname as for install/doinst.sh and
2) add (echo >>) it's name to /var/lib/pkgtools/packages/$shortname file, so removepkg deletes it as any other regular installed file.

Last edited by bormant; 04-01-2020 at 01:50 AM.
 
Old 04-01-2020, 03:37 AM   #19
GazL
LQ Guru
 
Registered: May 2008
Distribution: CRUX
Posts: 5,519
Blog Entries: 14

Rep: Reputation: 3345Reputation: 3345Reputation: 3345Reputation: 3345Reputation: 3345Reputation: 3345Reputation: 3345Reputation: 3345Reputation: 3345Reputation: 3345Reputation: 3345
A removepkg --skip-douninst flag to allow control over this new post-processing feature might not be a bad idea.
 
Old 04-01-2020, 12:21 PM   #20
bifferos
Member
 
Registered: Jul 2009
Posts: 367

Rep: Reputation: 136Reputation: 136
Quote:
Originally Posted by GazL View Post
A removepkg --skip-douninst flag to allow control over this new post-processing feature might not be a bad idea.
I think if I needed this option I'd be paying a visit to the script directory sooner or later to sort things out. Probably better if it's sooner.
 
Old 04-01-2020, 07:07 PM   #21
bifferos
Member
 
Registered: Jul 2009
Posts: 367

Rep: Reputation: 136Reputation: 136
I added a douninst.sh script to my pypi slackbuild generator and it seems to work much as expected. In this example, the doinst.sh script does the 'pip install' and the douninst.sh does the 'pip uninstall'. You may have good reason to not want your module installs working like this, but at least you have the option now.

https://github.com/bifferos/afterpkg...ce961af493be24
 
Old 04-02-2020, 09:01 AM   #22
bormant
Member
 
Registered: Jan 2008
Posts: 380

Rep: Reputation: 211Reputation: 211Reputation: 211
@volkerdi
This half-consistent way for install/doinst.sh and install/douninst.sh can be added with:
Code:
--- a/installpkg	2019-10-04 09:05:27.000000000 +0300
+++ b/installpkg	2020-04-02 17:02:34.359923861 +0300
@@ -697,9 +697,14 @@
       cp $ROOT/$INSTDIR/doinst.sh $ADM_DIR/scripts/$shortname
       chmod 755 $ADM_DIR/scripts/$shortname
     fi
+    if [ -r $ROOT/$INSTDIR/douninst.sh ]; then
+      cp $ROOT/$INSTDIR/douninst.sh $ADM_DIR/douninst.sh/$shortname
+      chmod 755 $ADM_DIR/douninst.sh/$shortname
+      echo var/lib/pkgtools/douninst.sh/$shortname >> $ADM_DIR/packages/$shortname
+    fi
     # /install/doinst.sh and /install/slack-* are reserved locations for the package system.
     # Heh, not any more with a recent tar :-)
-    ( cd $ROOT/$INSTDIR ; rm -f doinst.sh slack-* 1> /dev/null 2>&1 )
+    ( cd $ROOT/$INSTDIR ; rm -f doinst.sh douninst.sh slack-* 1> /dev/null 2>&1 )
     rmdir $ROOT/$INSTDIR 1> /dev/null 2>&1
   fi
   # If we used a scan directory, get rid of it:

Last edited by bormant; 04-02-2020 at 09:05 AM.
 
Old 04-04-2020, 05:00 AM   #23
NonNonBa
Member
 
Registered: Aug 2010
Distribution: Slackware
Posts: 147

Rep: Reputation: Disabled
Hi,

Sorry to come after the battle, but if we agree the stuff left by a package is just a loss of bits crowding some dirs, wouldn't it be more elegant to leave this to the local admin. A general hook would IMHO be more flexible and powerful. We could imagine, let's say /etc/postpkgtools.sh which would be ran after ANY package-related operation:

Code:
# A package was added
/etc/postpkgtools.sh LONG_NEW_PACKAGE_NAME
# A package was upgraded
/etc/postpkgtools.sh LONG_NEW_PACKAGE_NAME LONG_OLD_PACKAGE_NAME
# A package was removed
/etc/postpkgtools.sh - LONG_OLD_PACKAGE_NAME
It is easy for an administrator to know which file is moved from /var/.../scripts and to determine if it's worth to be removed. Plus, this would allow to automate (among ANYTHING else) the update of the kernel initrd, which could interest many users.
 
Old 04-04-2020, 11:04 AM   #24
bifferos
Member
 
Registered: Jul 2009
Posts: 367

Rep: Reputation: 136Reputation: 136
I don't think it's just about some files left behind. What about users? Groups? Could these represent security vulnerabilities? What about generated kernel modules that may get loaded and then forgotten about long after the package that created them has been removed?

I'm unsure as to why you'd want package-specific behaviour put in a system-level file like that. Won't that mean /etc/postpkgtools.sh ends up as a mass of hard to maintain if clauses? Or did you imagine some additional sub-system to execute per-package helpers, e.g. /etc/postpackagetools.d?

IMHO the current implementation is pretty much perfect. It's the absolute minimum you could get away with and that's frequently the best solution. I don't care about package renames, and don't really understand the post from bormant. Is that happening all the time? When did it last happen? Would the package that it happened to have benefited from douninst.sh in the first place?

For kernel initrd, isn't that something that could be done in the doinst.sh (assuming there's desire), and not really anything to do with douninst.sh?
 
1 members found this post helpful.
Old 04-05-2020, 08:14 AM   #25
NonNonBa
Member
 
Registered: Aug 2010
Distribution: Slackware
Posts: 147

Rep: Reputation: Disabled
I don't see any issue with groups and users. Unless you do a full install and manually merge your passwd/groups with updated defaults, you always have useless groups and users on a system. Plus, it is far easier to find the leftovers of a removed service if you have still a user name instead of just an empty UID number.

Touching what is loaded, it is the same issue when you upgrade, let's say, openssl. You have to kill and respawn everything is using it in order the old code to be actually removed. I don't think you would want the doinst.sh to even try to do that for you, as you certainly wouldn't call the glibc upgrade going on its own to telinit 1 a great feature.

The fact is that for 25+ years this mechanism hasn't been required by anything, so maybe the rare corner cases for it can be left to the admin (also notice the doinst.sh can handle the upgrading process, this is really useful only when you definitively remove something) rather than adding code you will have to care about as the pkgtools will evolve. That's why I think it's a better idea to just allow to the admin to automate what he already manually does after the package manager has completed its job (whatever it is, not just removing). And yes, the admin could split things in /etc/postpkgtools.d, as well as running any crazy things he wants from the script, that's the idea, but I'd be surprised this one would grow that big.

There are also some issues with the current mechanism, as now a removal can break something as soon as two packages share files, which was till now hardly thinkable (only when a tracked file in a package is generated in another). For example, the user has ABC installed, but gives a try to CDE, which is its forks. Then he chooses to keep the last and removes the former, but breaks all, because both generate a required file from the doinst that has been undoinsted since the packager of ABC couldn't even know it would be forked when he did the package.

That's why I think we now have a more complex and weaker code than before, for an unobvious gain. Hence my (IMHO very Slackware) suggestion: trust the admin and let him hammer his own fingers (Le métier qui rentre !, as we say by there).

Last edited by NonNonBa; 04-07-2020 at 08:40 AM. Reason: we're still saying it
 
1 members found this post helpful.
Old 04-05-2020, 05:12 PM   #26
bifferos
Member
 
Registered: Jul 2009
Posts: 367

Rep: Reputation: 136Reputation: 136
Quote:
Originally Posted by NonNonBa View Post
The fact is that for 25+ years this mechanism hasn't been required by anything
How would you know?

Quote:
There are also some issues with the current mechanism, as now a removal can break something as soon as two packages share files
I'm unsure why you'd want two packages to share files. Isn't that something to be avoided? Or, perhaps, packages that share files simply don't use douninst.sh? You're not obliged to use it.

Quote:
That's why I think we now have a more complex and weaker code than before, for an unobvious gain.
I don't consider the removepkg change as complex or weak, so I guess you mean the *use* of that code will be complex. If there is no obvious gain, then nobody will use it. If nobody uses it, then there's no complex, weaker code. It just does nothing. I think you're being a little paranoid if you think everyone's going to start using this overnight, given that most slackbuild maintainers have other jobs and want to do the minimum that keeps their builds working. There is little use for it in the core distro either because the maintenance tasks there are well established and documented and nobody wants to change workflows that have been in place for decades. Personally I'll be using this in my own private package builds as my SBo ones have no use for it, but rest assured I will be using it, and it will help me a great deal.

Quote:
Hence my (IMHO very Slackware) suggestion: trust the admin and let him hammer his own fingers
You could also trust the package maintainer to write a pragmatic douninst.sh. Clearly if I fill it with daft code it's not going to work properly. There's a solution to that....
 
Old 04-05-2020, 05:18 PM   #27
Richard Cranium
Senior Member
 
Registered: Apr 2009
Location: Carrollton, Texas
Distribution: Slackware64 14.2
Posts: 3,714

Rep: Reputation: 2061Reputation: 2061Reputation: 2061Reputation: 2061Reputation: 2061Reputation: 2061Reputation: 2061Reputation: 2061Reputation: 2061Reputation: 2061Reputation: 2061
Quote:
Originally Posted by bifferos View Post
I'm unsure why you'd want two packages to share files. Isn't that something to be avoided? Or, perhaps, packages that share files simply don't use douninst.sh? You're not obliged to use it.
I guess you'd be surprised on some of the things that happen in Slackware as it is delivered. There's a reason why removepkg checks to see if a file also belongs in another package from the one being removed.
 
1 members found this post helpful.
Old 04-05-2020, 06:46 PM   #28
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 7,248

Rep: Reputation: 4942Reputation: 4942Reputation: 4942Reputation: 4942Reputation: 4942Reputation: 4942Reputation: 4942Reputation: 4942Reputation: 4942Reputation: 4942Reputation: 4942
Quote:
Originally Posted by bifferos View Post
I'm unsure why you'd want two packages to share files. Isn't that something to be avoided? Or, perhaps, packages that share files simply don't use douninst.sh? You're not obliged to use it.
Quote:
Originally Posted by Richard Cranium View Post
I guess you'd be surprised on some of the things that happen in Slackware as it is delivered. There's a reason why removepkg checks to see if a file also belongs in another package from the one being removed.
It probably also wouldn't be very hard to do a sanity check of any potentially removed files in the douninst.sh to ensure they don't belong to any other packages. This is already done with .new files in the doinst.sh. There's probably a better, cleaner, or more efficient way to do this, but something like this should work:

Code:
checkdup() {
  REMFILE="$1"
  count=0

  for i in /var/lib/pkgtools/packages/*; do
    if grep -q "$REMFILE" "$i"; then
      ((count++))
    fi
  done

  if [ $count == 0 ]; then
    rm -f "$REMFILE"
  else
    echo "$REMFILE was found in $count package(s). Skipping."
  fi
}

checkdup etc/mycustomfile
 
Old 04-06-2020, 07:02 AM   #29
NonNonBa
Member
 
Registered: Aug 2010
Distribution: Slackware
Posts: 147

Rep: Reputation: Disabled
Quote:
Originally Posted by bifferos View Post
How would you know?
Because "required" would mean it would be there yet, at least historically used by one official package.

Quote:
Originally Posted by bifferos View Post
Personally I'll be using this in my own private package builds as my SBo ones have no use for it, but rest assured I will be using it, and it will help me a great deal.
Then you act as an admin, not a packager (who is per se doing things for others). This is exactly what my suggestion allows you to implement among any other things:

Code:
if [ "$1" = "-" ] && [ -f "/path/to/uninstall/$2" ]; then
  ( cd /; sh "/path/to/uninstall/$2" )
  mv "/path/to/uninstall/$2" "/path/to/was_uninstall/$2"
fi
Quote:
Originally Posted by bifferos View Post
You could also trust the package maintainer to write a pragmatic douninst.sh.
You can't trust the packager, that's my point, because a packager just can't know nor anticipate what the other packagers do or will do, as there is no way to guess what a doinst generates (precisely the targets of the undoinst). More generally, except in some rare cases, a packager can't really know what an admin will want to keep or not and is then always prone to fight him.

Quote:
Originally Posted by bassmadrigal View Post
It probably also wouldn't be very hard to do a sanity check of any potentially removed files in the douninst.sh to ensure they don't belong to any other packages.
Sure, but you see? You're then partially re-implementing the core functionality of removepkg in a file ran from removepkg.
 
Old 04-06-2020, 08:43 AM   #30
bifferos
Member
 
Registered: Jul 2009
Posts: 367

Rep: Reputation: 136Reputation: 136
Quote:
Originally Posted by NonNonBa View Post
Because "required" would mean it would be there yet, at least historically used by one official package.
'required' and 'available' are two different concepts. Just because something is required doesn't mean it has to be available. I require it. I don't really understand your argument. Are you telling me I don't require it? How do you know what I require? Granted you can tell me how to achieve what I'm trying to do in some other way but what if I don't want to do it that way?

One could argue that installpkg is not really 'required' couldn't one? You could just make do with the tar command coupled with some manual steps and it'd be great because you as admin would know what's going on, etc..etc.. but at some point one wants to automate things. Slackware has always trodden a fine line between what it does and doesn't do for the admin and I doubt very much everyone will agree on where that line should be it's an ongoing conversation. What I don't understand is why you seem to be telling me I can't/shouldn't use any uninstall steps, and how it creates some kind of problem for either you or the wider Slackware community. It doesn't, this is simply my choice for my own systems.

Quote:
You can't trust the packager, that's my point
Then why would you use his packages? When you download the package, grep the contents for douninst.sh and if you find it choose to refuse on the basis that the maintainer is in your view incompetent :-).

Quote:
Sure, but you see? You're then partially re-implementing the core functionality of removepkg in a file ran from removepkg.
If I wrap a third-party package that is supplied with an install/uninstall script I'm only automating the execution of that script's uninstall option. That has zero to do with removepkg. If my douninst.sh script contains a 'pip uninstall XXX' line, then that also has zero to do with removepkg. Removepkg has no knowledge of pip installed packages at all. I don't really get your point.
 
  


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 04:07 AM.

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
Open Source Consulting | Domain Registration