guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: defining core modules


From: Ludovic Courtès
Subject: Re: defining core modules
Date: Mon, 28 Jan 2019 11:51:53 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Hello,

Ricardo Wurmus <address@hidden> skribis:

> for the past few days I’ve been trying to reduce the module closure of
> “coreutils” by inspecting the output of
>
>     guix graph -t module coreutils

Much appreciated!

For the record, this is important for several reasons: it makes it
easier for (guix self) and thus ‘guix pull’ to build modules in smaller
chunks, and it means we can reduce I/O and memory usage, especially now
that the new cache is in place (see
<https://issues.guix.info/issue/34060>).

> This has shown a number of modules that are much too large and pull in
> almost all other modules.
>
> I’d like to propose a reduction of the modules to a core set.  To ensure
> that they stay small we would move them to the directory
> gnu/packages/core/.  Adding new module references to any of the modules
> in that directory would only be permitted for very good reasons.
>
> What do you think about separating these modules?

I support the idea; I’m not entirely sure about the core/ name space but
that’s a secondary issue.

It may prove to be tricky though.  For example, the set of dependencies
of GCC has been steadily growing over the last few years.  Those, in
turn, may pull in all sorts of C, C++, and Python packages.  So the
notion of “core” is really a moving target.

> One place to start with is (gnu packages linux), which is huge.  (gnu
> packages base) only needs libcap and linux-libre-headers, however.
> These could be moved to gnu/packages/core/linux.scm.

Right.  Initially linux.scm was for “kernel + Linux-specific packages”.
I think we should change it to have:

  • linux.scm for the kernel, header, ‘perf’, and little more.

  • linux-specific.scm (or similar) for Linux-specific packages (ALSA,
    PAM, libnl, btrfs, FUSE, etc.)

Thoughts?

> Or we could give all the packages in the core set their own module.

I’m not a big fan of it, and this would have to be applied recursively…

Alternately, it’d be interesting to visualize clusters in whole package
graph and guide module layout based on graph metrics, though I don’t
know exactly how.

Ludo’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]