Completely by accident I have stumbled across what appears to be a bug in removepkg. In short, if the path to the package file given at install time starts with "./" (or simply includes "./") and the package tarball did not include a "./" entry, removepkg will not remove the package's files if called upon to do so in the future. For example, if a package is installed using
then its files will be correctly removed by running
If however the installation command was
then its files will not be removed by the removepkg command.

The cause of the problem is probably the logic used to set TRIGGER at line 354-355. The intent of the conditional is to select the block of lines which start with a "./" if such an entry is found (which will be the case with a fully slackware-compliant tarball). However, for packages which for one reason or another do not include this entry but which happened to have a leading "./" specified in their path at install time, the logic breaks down and results in an empty delete_list. The presence of "./" in the "PACKAGE LOCATION" tricks the script into thinking that there's a "./" entry in the file list when there isn't. Thus the sed command used to create delete_list returns nothing.

I suspect the fix is to use "^./" as the argument to fgrep in line 354. This will cause TRIGGER to be set to "^./" only if there really is a line which starts with "./": the inclusion of "./" in the "PACKAGE LOCATION" entry will be ignored for the purposes of the test.

There are potentially only hours to go before the release of Slackware 15.0 so I realise that it might be too late even for a bugfix (even though it would be nice). However, it would be good if a fix for this issue could be added to removepkg soon after the next development cycle begins.

This, has never happened here

Since the example quoted used an SBo package I strongly suspect it is a "properly formed" slackware package. That is, it includes the "./" entry at the start of the file list. In this case, the "./" entry is found by sed and everything is good. The issue occurs if the package's file list does not start with a "./" entry and the path to the package includes "./" somewhere in it.

While one could argue that the fault is in the package (for not including a "./"), many packages don't do this for one reason or another and pkgtools tries to support such packages anyway. For the most part this support works fine, but it's broken in circumstances described in my initial post.

Do you have a sample package to share? I'm not sure it's even possible for makepkg to generate something without a ./ directory.

EDIT: Never mind about the sample package; I managed to put something together without makepkg. And adding in the carat where you said did result in everything being deleted properly.

I think it's well summarized ;-)

Yes, I am fairly certain that the makepkg script will always include the "./" directory. The issue involves packages generated in other ways. Since pkgtools tries hard to work with such packages, it seems to me that the issue identified here ought to be addressed, especially since (as far as I can tell) it can be fixed with the addition of a single character (a "^") to the fgrep argument. To be honest, I think this ought to be done for consistency anyway since it is "^./" that sed ends up looking for by vitue of what TRIGGER is set to. The fgrep is checking for the existence of the token that will ultimately be passed to sed, so it ought to search for the exact same regex.

As to a sample package, it's fairly easy to create one:
If you install this package using
then it will be correctly removed using
However, if installation of the exact same package includes "./" anywhere in the name, then removepkg won't remove the package's files. Examples which will cause removepkg to fail:
Since pkgtools accept tarballs for installation without the "./" entry, it is reasonable to expect that they will uninstall. Having different behaviour at removal time just because "./" was used in the path to the package at installation is more than a little surprising.

The inconsistency is perhaps as important here as ideology. Leaving this issue unfixed on the grounds that it only affects mal-formed packages would be fair if installpkg rejected such packages. As it stands, installpkg is able to deal with packages which lack the "./" entry, and removepkg has a specific workaround for them too. It's just that the incomplete fgrep argument used as part of removepkg's workaround doesn't always work correctly for the reasons stated.

The packages I discovered this with are locally created using tar, not makepkg. makepkg is not used since running as root during package creation is awkward in the circumstances, and tar generally does the job. There's just this corner case that's triggered if one happens to use "./" in the path to the package at installation time.

I've tried with a package which I expect to have been created with 'makepkg' and I can install and remove it properly using the example you gave with the "./" in the package pathname:
And "# removepkg dosbox-0.74.3-x86_64-1alien" worked too.

Slackware is not forgiving when you make mistakes, which means either you learn fast or you move to a different distro...
Why would you create packages in a manner unsupported anyway?

OP already addressed that question, and also challenged the idea of it being "unsupported."