From: Thomas de Grenier de Latour <degrenier@easyconnect.fr>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Reverse dependency Scanning
Date: Mon, 25 Apr 2005 21:11:17 +0200 [thread overview]
Message-ID: <20050425211117.308c1693@eusebe> (raw)
In-Reply-To: <200504251452.33864.pauldv@gentoo.org>
On Mon, 25 Apr 2005 14:52:18 +0200
Paul de Vrieze <pauldv@gentoo.org> wrote:
> Making the diagram vertical would probably be a big improvement.
Yep, that's very true. I've uploaded (same url) a new version
which adds 'rankdir=LR' to the graph, and I also think it's
much more readable this way (on "medium size" package sure, it's
still and will probably always be absolutly messy on big packages
like mozilla for instance).
Another change I've made is the addition of a "-r/--real-paths"
option which make the script resolve all symlinks while searching
for packages owning some depended-on files. The point is that if
you don't do that, then it won't be accurate in finding deps: a
program may be linked to "/usr/X11R6/lib/foo.so" whereas the file
was installed as "/usr/lib/foo.so" for instance (or the opposite -
I've found both on my system actually).
The following example shows the difference i think:
http://tdegreni.free.fr/gentoo/xdtv-symlinks.ps
http://tdegreni.free.fr/gentoo/xdtv-realpaths.ps
(the ebuild is not from portage, so i'm the one to blame for the
/usr/X11R6/lib linkings)
The drawback of that "real-paths" approach is that you then can't
distinguish a dep on Bash (/bin/bash) from one on any Bourne shell
(/bin/sh), and that's why i made it optional. Probably the best
would be to do both kinds of search at once and show the
difference in the graph, or something like that...
> one thing I miss however is a destinction between libraries
> linked into the application, and those that only are taken in by
> another library. The so files do make this distinction so it
> should be possible to extract it.
If i don't misunderstand what you mean, then that was exactly the
point of a patch i've submitted 2 days ago, and which is in the
current depreverse version. Shared libs that are listed as deps
should be only those which are marked NEEDED in the objects
headers, not those that are indirectly linked to.
--
TGL.
--
gentoo-dev@gentoo.org mailing list
prev parent reply other threads:[~2005-04-25 19:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-23 10:15 [gentoo-dev] Reverse dependency Scanning Spider
2005-04-23 12:13 ` Juergen Hoetzel
2005-04-23 12:21 ` Thomas de Grenier de Latour
2005-04-23 20:36 ` Spider
2005-04-25 1:51 ` Thomas de Grenier de Latour
2005-04-25 9:29 ` Spider
2005-04-25 12:52 ` Paul de Vrieze
2005-04-25 19:11 ` Thomas de Grenier de Latour [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050425211117.308c1693@eusebe \
--to=degrenier@easyconnect.fr \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox