From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?G=C3=A1bor_Boskovits?= Subject: =?UTF-8?Q?Re=3A_Speeding_up_=E2=80=9Cguix_pull=E2=80=9D=3A_splitting_modules?= Date: Tue, 7 Jan 2020 21:14:18 +0100 Message-ID: References: <87k1657i7j.fsf@elephly.net> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:36092) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iovFK-0003d4-3s for guix-devel@gnu.org; Tue, 07 Jan 2020 15:14:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iovFI-00065P-Fo for guix-devel@gnu.org; Tue, 07 Jan 2020 15:14:33 -0500 Received: from mail-ed1-x535.google.com ([2a00:1450:4864:20::535]:43638) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iovFI-00063t-6J for guix-devel@gnu.org; Tue, 07 Jan 2020 15:14:32 -0500 Received: by mail-ed1-x535.google.com with SMTP id dc19so640130edb.10 for ; Tue, 07 Jan 2020 12:14:31 -0800 (PST) In-Reply-To: List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: zimoun Cc: Guix Devel Hello, zimoun ezt =C3=ADrta (id=C5=91pont: 2020. jan. 7= ., K, 19:38): > > Hi Ricardo, > > On Sun, 5 Jan 2020 at 21:38, Ricardo Wurmus wrote: > > > G=C3=A1bor once suggested an iterative approach of identifying the most > > important nodes in the package graph that should be moved to their own > > modules, so that we would end up with a package graph that looks less > > like a hair ball. I think it would useful to get a better view on the > > relationships between modules. > > I am not sure to correctly understand. What does it mean "the most > important nodes in the package graph"? > Does "important node" mean a package which appears as inputs in a lot > of other packages? I was suggesting the following idea: The underlying package graph is actually a DAG, so by splitting modules it = is possible to achieve a state where the module graph also becomes a DAG. The exact heuristic or algorithm of splitting was not defined. One idea which is quite cloes to my heart is to make a one package per modu= le rewrite, with possibly some grouping modules for convenience on top, but th= at was determined not to be feasible performacewise at the time. > > > Cheers, > simon > Best regards, g_bor --=20 OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21