From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id YPdaAtzsrGMVQQAAbAwnHQ (envelope-from ) for ; Thu, 29 Dec 2022 02:26:52 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id GOteAtzsrGOGJwEAauVa8A (envelope-from ) for ; Thu, 29 Dec 2022 02:26:52 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 7D1F5990A for ; Thu, 29 Dec 2022 02:26:51 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pAhgZ-000124-Tg; Wed, 28 Dec 2022 20:26:19 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pAhgY-00011p-CL for guix-devel@gnu.org; Wed, 28 Dec 2022 20:26:18 -0500 Received: from cyberdimension.org ([2001:910:1314:ffff::1] helo=gnutoo.cyberdimension.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim 4.90_1) (envelope-from ) id 1pAhgV-000576-Se for guix-devel@gnu.org; Wed, 28 Dec 2022 20:26:17 -0500 Received: from gnutoo.cyberdimension.org (localhost [127.0.0.1]) by cyberdimension.org (OpenSMTPD) with ESMTP id 86ac50ee; Thu, 29 Dec 2022 01:21:00 +0000 (UTC) Received: from primary_laptop (localhost [::1]) by gnutoo.cyberdimension.org (OpenSMTPD) with ESMTP id 86cd1064; Thu, 29 Dec 2022 01:21:00 +0000 (UTC) Date: Thu, 29 Dec 2022 02:25:34 +0100 From: Denis 'GNUtoo' Carikli To: "jgart" Cc: guix-devel@gnu.org Subject: Re: Stratification of GNU Guix into Independent Channels Message-ID: <20221229022534.6873a87b@primary_laptop> In-Reply-To: <84400bcea3eee39dc15d82812a8006bb@dismail.de> References: <84400bcea3eee39dc15d82812a8006bb@dismail.de> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.30; i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/JAe5po81w3Vaa74SHX_cdk6"; protocol="application/pgp-signature"; micalg=pgp-sha256 Received-SPF: pass client-ip=2001:910:1314:ffff::1; envelope-from=GNUtoo@cyberdimension.org; helo=gnutoo.cyberdimension.org X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list 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+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN ARC-Seal: i=1; s=key1; d=yhetil.org; t=1672277211; a=rsa-sha256; cv=none; b=r/VfJcsNJXHs9qYcIlno9DByBcvIMRqfR6ZVjwIlWWKZwC79tWSlVCd7/gDceMonCGA5Yq UHAXOhklkF1sSnVG5nzve8K3cJKcBX4S5QqKrdPU1tq4icbGGWAC9hP/XxiqezwjKSh7Bf NHfHlMyf37N65RpDQ/NgZoMdoi7QvSWOpGrtXOYQBn8VGrgeSWDv+q+GLRHvB5c3/LONd6 7AydSCYrA2/x0ewzi5AZwQS6BQZrqMzjsh95L2rphLD1GwAYSTWlSjZp+xbuWPphbRTEJL Zjk5EokJQsNXJr3as8cflG6AmG3AN2jva51k4M6sdIa/lETzBdi/7Q7sbZVf6g== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1672277211; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post; bh=2HlwyojAuJ8bkZWhObai1aOKsJHvcZvfwxnYEJFVl1E=; b=r4zr+FtgNmQ4z1TTNnx3Ri5n4/LzznYwStU2LdEwV4DX3y3MeYNQqCCfljdakRaG5BfObp eyI2A6Tz69o0Up5TSGtoaMRX5ap6Wd9knaSA5FxbLql+vqoHqs91L0HhcVkAYAwbP0BSZU +rUZVJHC4IeY0Z8ttzssxWbKiIUSJtXz97gpZ0KyaCuDlGsGA7steCtxn8wzT1efFnMbO+ TkH835YeWPLjj+69YSpoDCE4NPQAMF/5AZVMLbrY8zui4nmStG704V7BhNjzQDyDqS10qk KUTX7qnAk0bYSahJlI4gwTiejOKTmOC0AC3qkH+bvEWynFJ0ebu1QzUedH/IWw== X-Spam-Score: -2.93 X-Migadu-Queue-Id: 7D1F5990A Authentication-Results: aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=none X-Migadu-Scanner: scn0.migadu.com X-Migadu-Spam-Score: -2.93 X-TUID: HCJp+D2tb4TT --Sig_/JAe5po81w3Vaa74SHX_cdk6 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sat, 24 Dec 2022 03:49:30 +0000 "jgart" wrote: > Hi Guixers, Hi, > Should GNU Guix be a small core of packages (and services?)? I think it would also make sense to consider first find the features we want, and then look at how to get them, to see if that works better for us. For instance if the goal is to get faster updates, there might be other things that could be done to improve the speed way more than reducing the number of packages in the repository.=20 For instance making sure that there are substitutes might improve the speed a lot more. It might also be possible to optimize Guile more for some tasks. For instance: - Copying files on filesystems that have deduplication could be improved. - Maybe it is possible to substitute more things (like the things it builds when we do guix pull) or at least rebuilding only some of them (the ones that changed between the last git revision and the new one).=20 - It might also be possible to combine information from Guix weather with the current system or packages to see on which revision the packages ca be upgraded without having to recompile anything (unless we use non-substitutable packages) and update to that revision automatically. - etc. For some of these ideas, we would first need to benchmark somehow what is taking time during updates though, to make sure that the optimization really yields some gains. In my case I've already a clear use case (basically a non-substitutable package that consist of a huge data file) where optimizing Guile will yield a lot of performance improvements. If the idea is (also) to avoid using certain packages, it might make more sense to have a system to do that inside the current Guix source code.=20 For instance a user might want to make sure not to ship compiled zfs compiled kernel modules, though right now it's not a big issue as you need to manually select either zfs-auto-snapshot or zfs to get it, no other packages depend on it. So users usually won't accidentally install it. Another idea would be to have some flag to have only free culture licensed packages (like to avoid cc-nd non-functional data). Though I think that if we do something like that, it would complicate things a lot. Since Guix is meant to be reproducible, we would need to find a way to handle that kind of configuration in a reproducible way. So far the configurability has been integrated in ways that are not hidden for users. For instance if you use a package transformation, you are aware of it. Packages specific to CPU Microarchitectures[1][2] also need to be used specifically, and if I understand users often use package transformation for that. An easier way here would probably be to teach tools like guix lint to enable to check certain things, for instance with 'guix lint --extra-check=3D./my-checks.scm', or just to write a new tool or external tools for that. We can already use the Guix repl in guile scripts. Though here it would still be up to users to run the checks and try to fix things (for instance by using package transformations), but at least it would not complicate things in Guix. As for weather or not switching to a layered approach would improve development, some projects like openembedded/yocto did that. I've no idea why exactly they did it and what turned out to work well or not for their use cases, but to me the result looks really complex[3], especially if we want to do something like that with Guix. For instance we'd need to handle this layered approach in all the infrastructure, tools, and so on. Users would also need to know where to send patches, and if we try to autodetect that in the tools that receive the patches, it might becomes error prone. And we'd also need to make sure that layers stay compatible with each other. If everything is split, that's harder to do. I think that one of the big strength of Guix is precisely the fact that everything is well integrated together. And as far as I understand, here having a single repository makes it much easier to do that. As I understand Guix maintainers do care about giving some time to third party packages or channels to adjust for changes[4], though with a single repository we can more easily do changes and test them than if the changes would be scattered around multiple repositories. A single repository also ensures that everything stay consistent without much effort. References: ----------- [1]https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/maths.scm?i= d=3Dfddf1dc3aba3176b6efc9e0be0918245665a6ebf#n2762 [2]https://hpc.guix.info/blog/2018/01/pre-built-binaries-vs-performance/ [3]https://layers.openembedded.org/layerindex/branch/master/layers/ [4]"We recommend waiting until the next Guix release is out though, which could be a month from now, so that your channel remains usable by those who pinned an older revision of the guix channel."[5] [5]https://guix.gnu.org/en/blog/2021/the-big-change/ Denis. --Sig_/JAe5po81w3Vaa74SHX_cdk6 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEeC+d2+Nrp/PU3kkGX138wUF34mMFAmOs7I4ACgkQX138wUF3 4mNBYg//X933t/Vi2jHCxlTwZW+ynKCnBPjR6JNev6sQ2APm6PAhp5J1oi0EiFQc QG5OuoRyKXjyA20R4rs20k0KyTRztyJ3YIDL+TUBbs9Htp2WEGsJWbXg+KwJkmMF 3chIHLtn5NRf6wmMQoSOrkEkR0UhpieRUJ2GoNeNzxcMRo8lhJlmTeCUngBxnR6t 9KHkTXjXQ+MdZfL8qhVJQGQ69uyMskPSpzQ3Au/kJKPndgwAAu1PZiNXt7ku8Sae gl5bATAMyzg9AIVATrzVbDjkKD7xWAc9YrUvb4Cp5kIEwu8/C7VOovPI4KhANaaL fS8C0hPmnAAA481rw5BeXxCiok4Nyx5daZjLA0d0CiSv1qWIUsnneFb9coPRmGTp wJf9k0HEvHUwR0LUtyx7IkruPEoUj8FA/C7rkDY0Feid3BvKSgIrm11xVNfU8wI2 1/TZ862jok325Rnu9I7UmAF+6xMEc9nLxS0nGA64Q7rtO4ITlbxq7KYD6av+eu5/ uqGTz5K4ltrc/qR3hpm7r/GJFc0OPGPXf4Hwi5Q5M4K3tHaSYEjHTaBEZI3m3ZlZ CMjew6uP6UWCI81QF5GlfAXj3QD3hiPMtZ+KqRSMWEWgekDyyE+VljnghQxX2K0j TE0HbMfc6JkI+/cFsBgnKJeDK00XBAhveqduMh8/AHXGa1fK5A4= =0KrD -----END PGP SIGNATURE----- --Sig_/JAe5po81w3Vaa74SHX_cdk6--