Re: defining core modules

["Ludovic Courtès" <ludo@gnu.org>]

Hi,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

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

[...]

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

Agreed.

More generally, I think we should have LANGUAGE-CATEGORY.scm modules,
like {python,haskell}-{web,crypto}.scm, rather than catchall web.scm or
crypto.scm.

That way, at least for “non-scripting languages” (Haskell, OCaml, Rust,
etc.), the language packages would all leave in their own set of modules
that you won’t load unless you actually use the language.

(I’m drawing a distinction between “scripting languages”, namely Perl
and Python, and the rest, because those other languages tend to grow
package graphs that are very much independent from the typical GNU/Linux
C code base.)

Thanks,
Ludo’.