ports-mgmt/pkg (1.3.4) quiet delete doesn't
Decided that it was time to cleanup the pkg’s installed on my system. Since the other day I watched it take forever to update a port, that turned out to be a leaf package. Leftover dependency from something I choose not to keep around. There are also other big left over build dependencies that for whatever reason weren’t marked as automatic or removed automaticallly at the end of a portmaster (w/ –delete-build-only) run.
ports-mgmt/pkg_rmleaves, having coming up an ugly fix to finally
make it work for me… which later resulted in the
Well, I selected a bunch of packages, and then it disappeared for a long time to seemingly delete the packages. It locked the package db, because a while later while it was still hiding I had typed ‘pkg version -vIl<’ in another window to see if the list of ports I need to update had gotten smaller.
Eventually it returned, and reported that there were no more leaves. Which was odd, since there should be many packages
fpc- still to be removed. Suspect its a problem in the post 1.3.0 release of
1.3.1 was especially fun where it segv’d on install and left me without any
pkg, and re-bootstrapping it pulls in the
1.2.7 version where it’ll complain lots that the database is much newer than it expects.
There was a portmaster backup of the old package, but I couldn’t install it with a working
pkg. Eventually, I restored
pkg-static from backup….I had broken all 3 of my home FreeBSD systems. And, then locked it so that I could still update other ports without it trying to update to broken release.
A few hours later, 1.3.1_1 was released….before I got to it, 1.3.2 came out. Followed by an update to 1.3.3 and today the update to 1.3.4.
Looking at what pkg_rmleaves was doing.
pkg delete -q -y "$p" I narrowed the problem to the ‘-q’ switch.
And, while I was filling out the bug report, I peeked at the source code (since I don’t have portmaster clean after an
zen.) and found this:
rc is initialized as false, so if quiet the answer is always no! That’s not right.
query_yesno() been called….it understands the ‘quiet’ flag, with:
Guess I’m not getting to that new thing I was going to try to get going this weekend….