GNU bug report logs - #30710
guix graph gives duplicate nodes

Previous Next

Full log

Message #14 received at 30710 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Hartmut Goebel <h.goebel <at> crazy-compilers.com>
Cc: 30710 <at> debbugs.gnu.org
Subject: Re: bug#30710: guix graph gives duplicate nodes
Date: Wed, 07 Mar 2018 16:18:51 +0100

Hello,

Hartmut Goebel <h.goebel <at> crazy-compilers.com> skribis:

>> This is expected.  Strictly speaking, we’re talking about two different
>> package objects, hence the different IDs.
>
> I wonder
>
> a) whether it is useful to have different graph nodes for the same package.
>
> This is about usability of the resulting graph, esp. since this is the
> default graph output format. Does it help *users* for their analysis? Or
> is this some *expert* insight?

As explained in “Invoking guix graph”, the tool provides different graph
types, each at its own abstraction level.

The package graph is high-level, but as a side-effect it has this
artifact.

To developers it’s actually useful to see the graph of package objects.
There are cases where, with functions that return packages, you would
notice that you’re generating lots of package objects for the same
underlying derivation, which is super inefficient (in particular it
defeats memoization).

Most of the time, there’s exactly one package object for each
derivation; if not, that’s usually a bug.

> b) how there can be different package objects for the same package
>
> To my understanding, e.g. (gnu packages base) is loaded once, defining
> package object abcd once and assigning it to a variable. All packages
> referring to abcd use the some package object. So there should be only
> *one* package object.

(eq? foo (package (inherit foo))) => #false

Yet, these two packages map to the very same derivation.

HTH,
Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.