PPM shenanigans.... (Solved!)

[Mike Walsh]

Evening, all.

Without wishing to get into specific examples & Puppies (which I'm loathe to do at the moment, because I don't see that it has the slightest bearing on the question), how do you solve this one?

An application needs a particular dependency to run.

You go into the PPM, and find that the PPM says it's already installed.

So you search, manually & with pFind, to find that not the slightest trace of the item exists. You then go to install what the PPM says is already there, because in the older Puppies, you can do that; it will allow you to. But

.....oh, no; this modern Puppy insists that you can't install this item until it's first been uninstalled, and gets into a real strop, and gets its knickers in a twist over the issue.....and point-blank refuses to do what you want. In fact, I've noticed this seems to be an issue with several of the modern Pups running what I assume is the 'current' version of the PPM.

With the best will in the world, I totally fail to see how it's even remotely possible to uninstall what doesn't exist in the first place! Where IS the PPM getting this information from?? I can't be the only one who's encountered this, surely.....

Any advice will, as always, be much appreciated.


Mike.

[musher0]

Hi Mike_Walsh.

My most sincere sympathies! Also, I think you have a case against a
developer!!! (Whoever that person may be!)

But before I make enemies , have you looked for the package in the
.packages database?

Sometimes PPM gets its hair all tangled up when the package is NOT in
/usr/bin, but its "identity papers" are still in the "packages" directory.

PPM is like a bureaucrat, you know, the ones that will not believe you are
alive talking to them, because they have your death certificate on their
desk... (Very bad analogy, sorry; but I hope it illustrates the problem
well.)

The Puppy packages DB used to be in /root/.packages, but in very recent
Puppies, it is in /var/packages.

The formula would be:
Go inside /root/.packages or /var/packages (whatever the case may be)
and type
tree -fi -L 6 | grep < package > (without the chevrons).
"-L 6" means "six levels deep", which I think should be more than enough.
"-fi" means don't draw the ASCII tree branches, just list the files.

If there is an index card of the missing package in there, that formula
will tell you.

If you find the "index card" for the missing executable, double-check that
the executable does not exist, and then erase it. Once that is done, PPM
will stop playing the silly bureaucrat.

IHTH. Keep us posted?

[Mike Walsh]

Hi, musher0.

Ah. Now that's the sort of info I was looking for. Thank you.

I will indeed let you know how I get on. It'll probably be tomorrow before I give this a try, since bedtime is fast approaching, and I'm already yawning my head off. (Not a good time to be attempting something like this, I feel..!)

I knew there was a 'list' of the PPM's contents (or what it downloads during updates) somewhere, but it's not something I've ever had any reason to investigate. I think that time is fast approaching; certainly, I don't think any of the usual 'tips & tricks' advice given to folks regarding the PPM actually applies in this particular case.

We shall see.....


Mike.

[HerrBert]

I remember, i had to remove a DB-Entry from ~/.packages/woof-installed-packages to reinstall a package in a remastered puppy...
If

Code: Select all

grep ^<package> ~/.packages/*-installed-packages

finds a match, it also returns, if it's woof-, devx- or user-installed.

Though not sure, if it's

what I assume is the 'current' version of the PPM.

[Mike Walsh]

@ musher0:-

I'm feeling distinctly silly now.

The supposed 'missing' package dependencies, which were nowhere to be found yesterday, have now miraculously appeared as if out of thin air. I'm at a loss to explain it.

This wasn't a new install; it's an existing Pup that's been in use for several months. According to ' rt-clk->Properties', they seem to have been there since the start of September, so.....they must have been installed along with something else that wanted them. Yet yesterday, they were nowhere to be found.....and the app I was attempting to run definitely flagged 'em up as missing. And between shutting down last night, straight after my previous post, and booting back into this same Pup around 20 minutes ago, I haven't done a thing except browse the Forum. Weird.

So; 'Solved'.....yet a mystery, all the same. (Must be gremlins in the works, methinks! )

(*shrug*)

Thanks for the suggestion, anyway.

----------------------------------------

@ HerrBert:-

Sorry, must have missed your post, during the course of editing my own reply.

We-e-ell... What I call the 'current version' is v2.0. But this is 32-bit Upup Bionic, one of the newest Woof-CE Pups.....and I wouldn't like to say how many times mavrothal's masterpiece has been 'patched' and/or 'upgraded' during that time. v2.0 has been in general use for 2 or 3 years, now, don't forget.....and it's very rare for a 'core' Puppy item like the PPM to go that long without receiving summat in the way of 'tweaking'. At least, that's been my experience so far!


Mike.

[musher0]

Hi, Mike.

Gremlins, or tiredness, perhaps; the important thing is that's it's solved!

Don't worry about it too much. I'm no better.

Two days ago, I absent-mindedly removed a perfectly good utility from a
new Pup I'm working on, rsync. Yesterday, I tried to rsync (a kind of copy)
something, I couldn't do it, of course, and I got mad at the good people at
woof-CE, resorted to swearing, invoking the saints, etc.!

Here is where this is related to your thread. I had a copy, so I tried
installing it with petget. Petget said: "N0-no-no, you already have it." Like
it said to you. Which led me to investigate and discover my snafu.

I could've removed the rsync index card, but instead I chose to unpack the
pet file with SFR's UEXtract, and copy the files individually from there to
where they should go. I.e., the "other way" to solve this problem. I forgot
to mention it yesterday.

IHTH. BFN.