Re: Is there an easy way to find out which port loads which library?

--- On Mon, 2/18/13, Chris Rees <utisoft_at_gmail.com> wrote:

From: Chris Rees <utisoft_at_gmail.com>
Subject: Re: Is there an easy way to find out which port loads which library?
To: "Jeffrey Bouquet" <jeffreybouquet_at_yahoo.com>
Cc: "FreeBSD Mailing List" <freebsd-ports_at_freebsd.org>
Date: Monday, February 18, 2013, 1:01 AM

On 18 Feb 2013 05:35, "Jeffrey Bouquet" <jeffreybouquet_at_yahoo.com> wrote:
>
>
>
> 
> >Subject: Re: Is there an easy way to find out which port loads which
library?
> 
> >Bernard Higonnet wrote:
>
> > Is there a simple, direct, complete, and unequivocal way to find out
> > which port(s) install which libraries?
>
> >Something like this perhaps?
> ># grep libfoobar.so /usr/ports/*/*/pkg-plist
>
> >AvW
>
> None of these replies mention
> pkg which /usr/local/lib/libfoobar.so
> pkg_which /usr/local/lib/libfoobar.so
> ...
> I typically use one or both (still using /var/db/pkg after running pkg2ng
once a
> long time ago...)

>Why???

>Chris

Unsure of the question.

Why did I run pkg2ng?  I was uncognizant of all the immediate consequences.
Why did I revert?  Not ready to make /var/db/pkg disappear until I've seen 
guides explaining the new usages which fit the present workflow here...

Why do not I implement it at this time?  I've still too much to do in the short term
on a daily basis vs. implement anything new until I am one of the *last* to do so, so I would do it in the quickest and most expedient manner. 


pkg_delete -f /var/db/pkg/rubygem-mime-types-1.19 && pkg_add rubygem-mime-types-1.21.tbz.
I don't have to know the 1.19 (the shell does).  I do not recall anyone mentioning how the
equivalent would work in a pkg system.  They may have, but if it was a reply, I
archived it somewhere, as I would prefer to switch all the machines I use weekly
all at once, and prefer to wait as long as expedient.

That works on legacy laptops as well as modern 4-core CPU, aided by the shell doing expansion, and I can type it without thinking, aided by the shell.
The subdirectory is directly available to grep, awk, less... without an .so.
I've not yet had time to implement a /var/db/pkg/ on  a machine running pkg
(by script maybe) so that it could continue.

I've posted several times why the progress of /pkg/ has not been shown to [1] not slow down the workflow to which I am accustomed to upgrade multiple machines has not been reliably demonstrated... and edge cases in which the legacy method is
preferable.  Unfortunately, I ran out of time a long time ago to respond more in
depth; my views on the matter are scattered in the lists archives and forum archives
[further content redacted so as to not waste anyone's time.]

J. Bouquet

[1] I am not asking for anyone's efforts, 
nor trying to sound negative;
just trying to respond to the question with a wait-and-see 
viewpoint...