Re: Build dependency inflation (was: Re: Core-updates merge)

[Simon Tournier]

Hi,

On jeu., 27 avril 2023 at 19:56, Simon Josefsson via "Development of GNU Guix 
and the GNU System distribution." <guix-devel@gnu.org> wrote:
> Andreas Enge <andreas@enge.fr> writes:
>
>> - Too much in Guix depends on too much else, which makes building things
>>   needlessly entangled; in particular time zone data should not be referred
>>   to by packages, but be loaded at runtime (Leo Famulari).
>
> This is an important open problem -- is there any way to attack this
> problem in a systematic way?  I guess it is hard to understand which
> packages ends up depending on what since it is a large graph with long
> cycles, and also to understand which build depencies are essential and
> which are superficial, and thus consequently challenging to know where
> to start working to reduce build dependencies?

Hum, I am not to get the “large graph with long cycles” part.  Since the
graph for packages is a DAG.

Well, “guix graph” and “guix graph --path” help to spot the chain of
dependencies between two packages that seem unrelated.

>From my point of view, we should increase the tooling to inspect these
graphs.  Other said, add feature to “guix graph”.

At some point, it could be nice to have “guile-igraph” a Guile binding
of igraph [1].

Last, back on December [2], I started to apply some well-known network
algorithm (link analysis, centrality measure, pagerank, etc.) to the
graph of packages.  From my point of view, these kind of tools could be
very helpful to spot out the packages that need some specific care.

Maybe it would fit a project for a student. ;-)


1: https://igraph.org/
2: https://yhetil.org/guix/874ju4qyd4.fsf@gmail.com
   Some stats about the graph of dependencies
   Fri, 09 Dec 2022 18:29:43 +0100
   id:874ju4qyd4.fsf@gmail.com


Cheers,
simon