On Sun, Oct 07, 2007 at 08:35:10AM -0500, Aaron Griffin wrote:
On 10/7/07, Travis Willard <travis@archlinux.org> wrote:
On Sun, 7 Oct 2007 08:35:10 -0400 Travis Willard <travis@archlinux.org> wrote:
This is what I use for checking the deps:
[andyrtr@workstation64 cvs]$ grep -l libpcap `find . -name PKGBUILD`
A while ago I posted a script to this ML that does this, but gives more concise output, finding _only_ deps and makedeps, and not random comments and such.
Jurgen reworked it a bit for speed and because his bash is leet.
I've reattached it here - I suggest you use it.
That's... odd. I could swear I attached it - I remember going through the dialogs and everything.
Trying again.
Well that worked.
Still this script is more of a fancy grep than what andy intends, I think.
I think what he wants is some recursion here to see if a depend is REALLY a depend, just not explicitly listed in the PKGBUILD.
There are cases (usually with good programs) where things are in the dependency tree but not actually link-level dependencies. Lib A depends on libcap, App A depends on Lib A but doesn't link to libpcap itself. Walking the dependency tree, you'd see this case and you wouldn't know if it was a link level dependency or not. It's just as likely that Lib A depends on libpcap and App A also depends on libpcap. Should we start making a distinction for this? The namcap depends rule could be changed to cover this case... it'd take a while to do properly though. Jason