Hi,
Danny Milosavljevic <dan...@scratchpost.org> skribis:
> On Mon, 28 Jan 2019 11:51:53 +0100
> Ludovic Courtès <l...@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’.
