GNU bug report logs - #54539
[PATCH 0/6] Start breaking up import cycles

Previous Next

Full log

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxime Devos <maximedevos <at> telenet.be>
Cc: 54539 <at> debbugs.gnu.org
Subject: Re: bug#54539: [PATCH 0/6] Start breaking up import cycles
Date: Tue, 19 Apr 2022 11:17:18 +0200

Hi Maxime,

Maxime Devos <maximedevos <at> telenet.be> skribis:

> Import cycles make some packaging things harder and prevent some
> proposed optimisations to "guix pull", let's start eliminating them.
> TBC ...

Sorry for the late reply.

Some of the changes you propose may make sense (and should be applied),
but we shouldn’t overplay the role of such changes.

If you follow the logic, breaking up import cycles would mean, in the
end, having one file per package.

But would that be enough?  Probably not, because low-level packages are
bound to depend on high-level packages—e.g., glibc depends on Python,
some other low-level tool might depend on Pandoc (GHC), librsvg depends
on Rust, and so on.

IOW, since the graph of build dependency really is a graph, and not a
tree, there’ll always be import cycles.

(guix self), the module that ‘guix pull’ uses, already automatically
splits package modules into two groups.  It’s not as modular as we’d
like, but it’s a start.  What would be useful is to come up with metrics
and tools to reduce the closure of the “guix-packages-base” group.

WDYT?

Thanks,
Ludo’.

Previous Next

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