Uninstall local pkg - Failed to find a match

Seem to be unable to uninstall the packages I installed here.

$ pkgman search --detail heron
Repository  Name   Version   Arch
----------------------------------------------
<system>   heron    1.0.11-2  x86_gcc2

$ pkgman uninstall heron
** Failed to find a match for "heron":  Name not found

It isn’t just this package. I’ve tried with version numbers. haikudepot same error. Remove the file from /boot/system/packages and reboot?

Where did you find this package? It doesn’t seems to be in the repo. In any case it looks like the package is badly made and doesn’t provide internal name “heron”. This is where pkgman looks for when doing install/uninstall.

You can just delete it from /system/packages, no need for reboot.

I found the package on my hard drive, after I wrote and compiled the contents.

.PackageInfo has a “name” value -

name heron
version 1.0.11-2
architecture x86_gcc2
... etc.

Note that pkgman search can find it just fine, by that name “heron”.

Correct .PackageInfo should have this section:

provides {
	heron = 1.0.11
}

Indeed, pkgman searches inside package description.

Probably we should make the “package” tool reject packages that don’t provide their name. Is there a ticket about that?

2 Likes

Is this not a must have option during creating a package? I think so.

It might be easier to avoid the need for this.

I mean, I checked, and Diver’s right - it was the “provides” declaration that was missing, and after that was added, the package can be uninstalled.

Then I tried removing the “name” declaration, and package create failed with “name is not being set anywhere!” And likewise for version. So yes, package could require the provides declaration also, with I’d suggest an error message like “-> package heron 1.0.11-2 doesn’t have any name or version number!” That will give them something to think about!

Or it could just use the name and version number it already has, from the name and version parameters.

Also, I tried “provides { somethingelse = 1.0.12.0 }”, and package create accepted this without comment. Don’t know how this would behave when installed, I’m not going to try that (on purpose anyway, but it’s a sure thing that it has happened by accident, at least a version number mismatch.)