Ludovic Courtès <l...@gnu.org> writes:
>> 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. Yeah, a minute after sending out this email I noticed the same problem :) >> 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? I agree. I’m working on linux.scm already. I wasted some time on splitting guile.scm, which is difficult as package-for-guile2.0 cannot be used. This needs to be done as all these other Guile bindings pull in many modules. I wonder if we can get rid of the package-for-guile2.0 variants. > 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. I’d love to have better visualisations as well. One thing that helped me identify the next steps to change was to look for modules that a) have been added for just a handful of packages they provide and b) that depend on many other modules. -- Ricardo
