Hi,

On Mon, 28 Jan 2019 11:51:53 +0100
Ludovic Courtès <ludo@gnu.org> wrote:

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

I support the idea, too.

> It may prove to be tricky though.  For example, the set of dependencies
> of GCC has been steadily growing over the last few years.

Yeah, it's worrying.  Minimalism is truly rare nowadays :(

> > 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.)

In general I would always prefer that (I thought the python-xyz was
something like that for python).

There's a difference between "A" and "written using A" (even if it's an
extension to A), and it doesn't make much sense to conflate them.

For example, CPython is a C program and it doesn't make much sense to
put it with the Python programs (pypy, on the other hand, is a Python
program).  CPython won't use any of them.

So CPython itself is in gnu/packages/python.scm and the Python
modules are NOT in gnu/packages/python.scm, but for example in
gnu/packages/python-xyz.scm or more specific modules.

In your case, gnu/packages/linux.scm would be the Linux kernel and
gnu/packages/linux-xyz.scm would be packages that only work on the
Linux kernel (i.e. *clients* of the Linux kernel).

Otherwise, there are all kinds of circular dependencies (for example
for the build systems) which are just there because the build system
wants to use the compiler, but the packages using the build system are
in the same module as the compiler for no reason.  Worse, among the
packages using the build system are bindings for half the universe,
whose guile modules now also get pulled in.

Once a compiler starts to self-host, that's more difficult of course.

In the end, we move packages only when there's a good reason - but right
now, avoiding unresolvable dependency cycles is a serious drain on
everyone's time (I still feel kinda bad in the stomach whenever I add a
#:use-module -- even after I wrote a silly tool to find the cycles, most
of which are harmless and thus false positives).

That's in addition to the problem that packages pull in half the universe
if you aren't careful, which is much worse.

If there was a "core" namespace, at least one could be reasonably sure
that these don't pull in non-core modules (if we enforced that when
reviewing), making the module closure smaller and problems more
manageable.

I think it's worth a try to talk to upstream if there are outrageously
large or numerous dependencies to something and try to convince them
to reduce them.  After all, it only increases bug surface, including
security bug surface, to have many large dependencies (it's a cost).