[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Extracting a reachability path out of a (package) DAG
From: |
Nils Gillmann |
Subject: |
Re: Extracting a reachability path out of a (package) DAG |
Date: |
Tue, 17 Jul 2018 08:24:24 +0000 |
Björn Höfling transcribed 74K bytes:
> Hi Guix,
>
> we have this nice `guix graph` tool which outputs DAGs of the packages
> (or even derivations,bags, ...). This is cool if you look at simple
> packages like the "hello" package with little to no dependencies. If
> you look at "real" packages like qt or maven the information is just
> overwhelming and you are scrolling around the image for just getting a
> headache.
>
> Often the only think I want to know is something like: Why is "goodbye"
> a dependency of "hello"?
>
> To answer this, I want to extract from hello's package graph the path
> (more precisely: the sub-DAG) leading from the root "hello" to the
> target node (or even nodes) "goodbye".
>
> After several attempts and failures, I wrote a script for gvpr from
> the GraphViz suite that does the job.
>
> Example 1: In bug #30710 Hartmut Goebel asked why qt depends on two
> different autoconf-wrapper packages. To answer that, you can find out
> the two node names from the .dot file and then call:
>
> gvpr -f markpath.g -a "ex 64168128 64167936" < qt-thing/qt.package.dot
> >qt-acw.dot
>
> This extracts (ex) the path (sub-DAG) to the two seed nodes and outputs
> it in a new graph. This result is quite compact with only 12 nodes (attached).
>
> Example 2: How/Why is glib a dependency of maven? The extracted graph
> has about 50 nodes, so I don't attach it here. You will see that
> java-logback-classic depends on a groovy-cluster that finally mounts
> into antlr. That depends on a gtk/pango/cairo-cluster that finally
> sinks into glib.
>
> Hope that is useful to someone else,
>
> Björn
>
>
To add to this idea:
abyayala$ nix why-depends --help
Usage: nix why-depends <FLAGS>... <PACKAGE> <DEPENDENCY>
Summary: show why a package has another package in its closure.
Flags:
-a, --all show all edges in the dependency graph leading
from 'package' to 'dependency', rather than just a shortest path
--arg <NAME> <EXPR> argument to be passed to Nix functions
--argstr <NAME> <STRING> string-valued argument to be passed to Nix functions
-f, --file <FILE> evaluate FILE rather than the default
-I, --include <PATH> add a path to the list of locations used to
look up <...> file names
Examples:
To show one path through the dependency graph leading from Hello to Glibc:
$ nix why-depends nixpkgs.hello nixpkgs.glibc
To show all files and paths in the dependency graph leading from Thunderbird
to libX11:
$ nix why-depends --all nixpkgs.thunderbird nixpkgs.xorg.libX11
To show why Glibc depends on itself:
$ nix why-depends nixpkgs.glibc nixpkgs.glibc
Note: this program is EXPERIMENTAL and subject to change.
Would it be useful to have a guix package subcommand which replicates this?
- Extracting a reachability path out of a (package) DAG, Björn Höfling, 2018/07/17
- Re: Extracting a reachability path out of a (package) DAG, Pierre Neidhardt, 2018/07/17
- Re: Extracting a reachability path out of a (package) DAG,
Nils Gillmann <=
- Re: Extracting a reachability path out of a (package) DAG, Björn Höfling, 2018/07/17
- Re: Extracting a reachability path out of a (package) DAG, Gábor Boskovits, 2018/07/17
- Re: Extracting a reachability path out of a (package) DAG, Pierre Neidhardt, 2018/07/21
- Re: Extracting a reachability path out of a (package) DAG, Alex Kost, 2018/07/22
- Re: Extracting a reachability path out of a (package) DAG, Pierre Neidhardt, 2018/07/22
- Re: Extracting a reachability path out of a (package) DAG, Björn Höfling, 2018/07/22
Re: Extracting a reachability path out of a (package) DAG, Ludovic Courtès, 2018/07/23