Why is "pkg_glob" no longer working for me?

[Tom Russo]

On Sun, Apr 28, 2013 at 12:00:02PM +0000, we recorded a bogon-computron collision of the <freebsd at chthonixia.net> flavor, containing:
> On Fri, Apr 26, 2013 at 02:54:59PM -0600, Tom Russo wrote:
> > 
> > Anyone else have this issue?  Or am I the only one left still using
> > portupgrade and its associated tools?
> 
> I use portupgrade and have noticed no failures. 

I use portupgrade and usually notice no failures.  But every once in a while
a package fails (for many reasons, either a download site that's down, or
some change has been made that makes one package conflict with another,
or you installed some dependent package with options that this new package
doesn't like, or...).  

> I have never used
> pkg_glob so I cannot address that. 

That's the only thing I have noticed that doesn't work.  Portupgrade itself
is fine.  But pkg_glob is part of the portupgrade package, so if the issue
is that it got broken in an upgrade, then it was an upgrade to portupgrade
that did it.

> I have used portupgrade as you, for
> many ports, and have always seen failures printed to my terminal at the
> end of the mass upgrade with an alert to that effect; just like for a
> single port. It seems that you are not seeing that report?

Oh, that works just fine.  I was simply tossing out a single use case in too 
terse a manner.  My apologies for oversimplifying.

Here's what I really meant by that example:

Let's say some package, foobar, has been updated, but lots and lots of
packages depend on it and UPDATING tells you to force upgrade everything
that depends on it.  So...

You run a "portupgrade -fr foobar" and after hours and hours of successful 
recursive portupgrading, some package (and everything that depend on it) 
fails.  You dig down to figure out why it failed (let's say, it was a broken 
download, or something really trivial like that), then fix the problem, and 
want the portupgrade to continue where it left off.  You don't want to just 
redo "portupgrade -fr foobar" because then it'll start all over, and it's
already tied up your machine for hours.  What you really want is:

   portupgrade -fr -x '>=(a date/time after portupgrade exited before)' foobar

But before you do that, you double check which ones will be upgraded now:
   pkg_glob -r -x '>=(the same date/time)' foobar

One assumes that if the latter gives you a list of packages that seems 
reasonable (and doesn't appear to list packages it already did successfully), 
then the former will only force upgrades to the same list.   

Now, the real reason I posted this message in the first place was that on
Thursday I did a portupgrade and it upgraded some 20 packages, all of them
successful.  

A day later, long after all traces of portupgrade output were gone 
from any screen I had, I discovered one of my projects for work started getting
build failures (related to /usr/local/lib/gcc46/libstdc++.so somehow not
being searched at link time, using precisely a (extraordinarily complex 
openmpi-based) build process that had worked perfectly on Thursday) --- 
and there had been no changes other than that portupgrade run (I started 
portupgrade before I left work on Thursday, and on Friday morning portupgrade 
was done and my work build was busted).  

Now, I needed to figure out what exactly had been done by that portupgrade, to 
track down why /usr/local/lib/gcc46/libstdc++.so was suddenly no longer being 
searched for externals when my code was linking, even though it had worked 
just yesterday --- clearly, some package that I'm actually using in this build 
got touched in some way, but which one, and how?  Pkg_glob is the tool that
could have helped me.

But pkg_glob no longer works to show me what, exactly, had been upgraded.  I 
still don't actually know what upgraded package broke my build, but I did 
ultimately find a workaround to get me past it.  It would be nice to be able 
to use that tool again, because it has come in very handy many times in the 
past.  Hence my original post, with a dramatically simpler and less verbose
use case described in the intro.

So, the question remains:  why did it stop working, and how can I make it work
again?

-- 
Tom Russo    KM5VY   SAR502   DM64ux          http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236        http://kevan.org/brain.cgi?DDTNM
 echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m]