From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Bj=C3=B6rn_?= =?UTF-8?Q?H=C3=B6fling?= Subject: bug#30710: guix graph gives duplicate nodes Date: Fri, 9 Mar 2018 11:09:17 +0100 Message-ID: <20180309110917.79b14a36@alma-ubu> References: <86fb9895-768a-bea0-154c-070861c0bb1d@crazy-compilers.com> <87d10i8mpb.fsf@gnu.org> <87efkvsylg.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/qRKTeZ4Jo12ZfRIU91s=wI8"; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:60551) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1euEyV-0003qn-Gn for bug-guix@gnu.org; Fri, 09 Mar 2018 05:10:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1euEyQ-0002Hh-6q for bug-guix@gnu.org; Fri, 09 Mar 2018 05:10:07 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:43852) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1euEyQ-0002HY-32 for bug-guix@gnu.org; Fri, 09 Mar 2018 05:10:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1euEyP-0005dz-N7 for bug-guix@gnu.org; Fri, 09 Mar 2018 05:10:01 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87efkvsylg.fsf@gnu.org> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 30710@debbugs.gnu.org, Hartmut Goebel --Sig_/qRKTeZ4Jo12ZfRIU91s=wI8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, 07 Mar 2018 16:18:51 +0100 ludo@gnu.org (Ludovic Court=C3=A8s) wrote: > Hello, >=20 > Hartmut Goebel skribis: >=20 > >> This is expected. Strictly speaking, we=E2=80=99re talking about two > >> different package objects, hence the different IDs. =20 > > > > 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? =20 >=20 > As explained in =E2=80=9CInvoking guix graph=E2=80=9D, the tool provides = different > graph types, each at its own abstraction level. >=20 > The package graph is high-level, but as a side-effect it has this > artifact. >=20 > To developers it=E2=80=99s actually useful to see the graph of package > objects. There are cases where, with functions that return packages, > you would notice that you=E2=80=99re generating lots of package objects f= or > the same underlying derivation, which is super inefficient (in > particular it defeats memoization). >=20 > Most of the time, there=E2=80=99s exactly one package object for each > derivation; if not, that=E2=80=99s usually a bug. >=20 > > 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. =20 >=20 > (eq? foo (package (inherit foo))) =3D> #false >=20 > Yet, these two packages map to the very same derivation. This thing really took me a while to think about the graph system in general and this concrete case. Speaking about this concrete case: If you inspect the output of=20 `guix graph qt` you find these interesting lines: "64168128" [label =3D "autoconf-wrapper-2.69", shape =3D box, fontname = =3D Helvetica "64167936" [label =3D "autoconf-wrapper-2.69", shape =3D box, fontname = =3D Helvetica "52941184" -> "64168128" [color =3D darkseagreen]; "52940800" -> "64167936" [color =3D blue]; "52941184" [label =3D "automake-1.15.1", shape =3D box, fontname =3D Helv= etica]; "52940800" [label =3D "libtool-2.4.6", shape =3D box, fontname =3D Helvet= ica]; If you look into gnu/packages/autotools.scm, you see that autoconf-wrapper is not a package, but a package-factory: (define* (autoconf-wrapper #:optional (autoconf autoconf)) Now the package definitions of "automake" and "libtool" each use the same fragment of code in their native-inputs, but a different "package" in the eq?-sense, although they basically want the same thing: `(("autoconf" ,(autoconf-wrapper)) As ludo stated above: "Most of the time, there=E2=80=99s exactly one package object for each derivation; if not, that=E2=80=99s usually a bug." This looks to me like a bug. Correction: (define autoconf-wrapper-default (autoconf-wrapper)) And then use this singular package as native-inputs to libtool and automake. Furthermore, when I search: find . -name "*.scm" -exec grep -H "autoconf-wrapper" "{}" ";" | less I find about 10 packages that use the fabrik, but all in the default way. So instead of: #:export (autoconf-wrapper)) We could just=20 (define-public autoconf-wrapper-default (autoconf-wrapper)) and use that. Or, if noone is using this fabrik, just drop that and make a normal package= out of it. WDYT? Reopen this one? Bj=C3=B6rn --Sig_/qRKTeZ4Jo12ZfRIU91s=wI8 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlqiXU0ACgkQvyhstlk+X/2guACggmTt9KBh6POkgal0Y6oFuiEy 2B0An1rE5zvKJHIFxz1BiCKNqP1+tYIu =wghw -----END PGP SIGNATURE----- --Sig_/qRKTeZ4Jo12ZfRIU91s=wI8--