Hello,

Nguyễn Gia Phong <[email protected]> skribis:

> I analyzed the official channel's dependency graph and it turns out
> quite some R packages are inputs of non-R ones, so the split
> would not be completely clean, however, if we do 300-dependent cutoffs,
> we would have 4 "rings" going inward of 30722, 1775, 348
> and 49 packages (the number could change a bit since I used
> last week's master, I'll follow up with the reprod scripts shortly).

On the general topic of splitting, there are several barriers.  The main
one is that there is no clear way to split the software we package.

It’s tempting to split by language, but that doesn’t work: eventually
glibc gets to depend on Python, librsvg on Rust, and some random R
package like ‘r-littler’ depends on GHC via Pandoc.

Note that (guix self) makes a semi-automatic split in two groups,
‘guix-packages-base.drv’ and ‘guix-packages.drv’ (which is what you see
when running ‘guix pull’).  Even this unambitious split is tricky
because the ‘base’ group ends up containing most package modules…

There are other barriers, having to do mostly with the inconvenience of
synchronizing separate repos compared to a single monorepo, which would
be a real step back IMO.

A fruitful approach might be to devise new inclusion criteria, such that
niche packages are pushed to external channels.  But that too is hard to
come up with and could be seen as arbitrary.  Tricky!

Ludo’.

Reply via email to