[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: defining core modules

From: Ludovic Courtès
Subject: Re: defining core modules
Date: Mon, 28 Jan 2019 15:25:59 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)


Danny Milosavljevic <address@hidden> skribis:

> On Mon, 28 Jan 2019 11:51:53 +0100
> Ludovic Courtès <address@hidden> 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).


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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]