[arch-dev-public] Find-deps script (was: hidden dependencies)
jason at archlinux.org
Sun Oct 7 15:42:24 EDT 2007
On Sun, Oct 07, 2007 at 08:35:10AM -0500, Aaron Griffin wrote:
> On 10/7/07, Travis Willard <travis at archlinux.org> wrote:
> > On Sun, 7 Oct 2007 08:35:10 -0400
> > Travis Willard <travis at archlinux.org> wrote:
> > > > This is what I use for checking the deps:
> > > >
> > > > [andyrtr at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the arch-dev-public