From mboxrd@z Thu Jan 1 00:00:00 1970 From: Danny Milosavljevic Subject: Re: defining core modules Date: Mon, 28 Jan 2019 13:19:06 +0100 Message-ID: <20190128131906.17f82625@scratchpost.org> References: <878sz5ssq1.fsf@elephly.net> <871s4xt5py.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/tv96Nh_jEyXxDbK9FmFmg27"; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([209.51.188.92]:44337) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1go5sh-0000bJ-Rd for guix-devel@gnu.org; Mon, 28 Jan 2019 07:19:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1go5sh-0000bV-0N for guix-devel@gnu.org; Mon, 28 Jan 2019 07:19:15 -0500 In-Reply-To: <871s4xt5py.fsf@gnu.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ludovic =?ISO-8859-1?Q?Court=E8s?= , Ricardo Wurmus Cc: guix-devel@gnu.org --Sig_/tv96Nh_jEyXxDbK9FmFmg27 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, On Mon, 28 Jan 2019 11:51:53 +0100 Ludovic Court=C3=A8s wrote: > I support the idea; I=E2=80=99m not entirely sure about the core/ name sp= ace but > that=E2=80=99s 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. =20 >=20 > Right. Initially linux.scm was for =E2=80=9Ckernel + Linux-specific pack= ages=E2=80=9D. > I think we should change it to have: >=20 > =E2=80=A2 linux.scm for the kernel, header, =E2=80=98perf=E2=80=99, and= little more. >=20 > =E2=80=A2 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). --Sig_/tv96Nh_jEyXxDbK9FmFmg27 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAlxO8zoACgkQ5xo1VCww uqX5KAf/b+zXgEDvQi3s4h3r8FlTcojJ5/RKtfAx54MPvJpzhhK5rIhXCpS+Md/B o5tSRf2kmYIjhKdywpUR7HHSj7qZwXxqQXTT5LOmMckQRqvaIk6a+XOWZI83DzyK fTcLjHckVeLJ847rT2YDhI+Dh67/pkPAV9bGdz5PGQkALWKDu5oPiimlP/uKJaz1 h4bf1npESs+evnmBM1IgWxW+oJmjlGzPhcVrm2zl8VfT/4kg7zMpfnyTZ/gKkLUs 1qvjcxaYZ4mBBCEVAfvY5v0jt6aqKxaREmeGYCVTlUtFcjjVWwniFGy2DJ46d3hT H/ma4uBZ9poRRfyo+/557prE71s9BQ== =k7yR -----END PGP SIGNATURE----- --Sig_/tv96Nh_jEyXxDbK9FmFmg27--