[arch-dev-public] Find-deps script (was: hidden dependencies)

[Jason Chu]

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
properly though.

Jason
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://archlinux.org/pipermail/arch-dev-public/attachments/20071007/adf9d533/attachment.pgp>