That sounds like a 21st century situation. Hopefully, it'll be resolved before the 2037 problem.

2038. We have an off-by-one error.

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.

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.

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

@volkerdi
This half-consistent way for install/doinst.sh and install/douninst.sh can be added with:

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:

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. :twocents:

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?

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

How would you know?

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 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.

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....:hattip:

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:

Because "required" would mean it would be there yet, at least historically used by one official package. :)

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:

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.

Sure, but you see? You're then partially re-implementing the core functionality of removepkg in a file ran from removepkg.

'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.

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 :-).

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.