From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id WIY9INMtdGKG3gAAbAwnHQ (envelope-from ) for ; Thu, 05 May 2022 22:04:35 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id gIAvINMtdGK5RQEAauVa8A (envelope-from ) for ; Thu, 05 May 2022 22:04:35 +0200 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 E4403291DE for ; Thu, 5 May 2022 22:04:34 +0200 (CEST) Received: from localhost ([::1]:36920 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nmhiE-0004Z7-11 for larch@yhetil.org; Thu, 05 May 2022 16:04:34 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52234) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nmgqR-00005k-GP for guix-devel@gnu.org; Thu, 05 May 2022 15:09:06 -0400 Received: from mail-ed1-x543.google.com ([2a00:1450:4864:20::543]:44870) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nmgqO-0007wV-PY for guix-devel@gnu.org; Thu, 05 May 2022 15:08:58 -0400 Received: by mail-ed1-x543.google.com with SMTP id t5so6269091edw.11 for ; Thu, 05 May 2022 12:08:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:subject:from:to:date:in-reply-to:references:user-agent :mime-version:content-transfer-encoding; bh=J7/HLhQ22T0TRyQ6xRs0bnkJOSg4bE8QYrV4+US2DfM=; b=VQGD1H1GY4b3XtRJRjLK7JsO9odFxcpde5mMuJd1FJcs67IAxzIWQgkvKrrnz7aBUz r006eQfxduFyxrbHquGdKXfaC8cM4H/1dzJihhdooMtU0CYWMHW/OugZJMNCfWUxIIBz P/c3Q1asXtloxfZglGTIDuqY7bunQs9/xB6LYaFxSdmg3biB2AStoZGtnRTqjqGSIjhi aTC4W+asq8lbETpdxwXHl6o6RzEC7/K8/MhgdR+uJJPA+zc2oJZR4+YjkPDM4xqSQ+77 gZue91qDldR8yZNjd+VSC3hJvPmwdHPes8+A5Y3G6r5e3xdqOuj4pJdPl2RkV16PTVXe 0k1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=J7/HLhQ22T0TRyQ6xRs0bnkJOSg4bE8QYrV4+US2DfM=; b=AsvgFnx+YEUMVgjxr1CI2UcVV+iBheXYLnjKMT23rtq5YK1HGfp7/6xg5apfTsNjwp Houd7LL7SzcDwNbEL0ZnO1glwypLaSqc2VLQfKZVZT6EcGScvJGxH3kU7iqmgM+icie7 /eKQIu3kGxGQXf51IBC4+KUfNuZjVNHkuRKTZ77FEheHDdHkpNLaYndE7U6X6DtcmATX Zp1v/HH5rNC2C/sNl14fAL1W2ziPe/QveM8HogcV7/fdlya4+zb8JQFM5KeBy9hY3FaG zDTR9rBxTPzq+d0gtue4dJBMifjLnwF6LotIv3mjT/KFLID5E858NofGPAEo09/agt6w Uauw== X-Gm-Message-State: AOAM533V4sG4YErBM+Bhquk/I0pfIb8/2wG999naXwiLZil8Nd8yLGyx Z7BlzBU5MzwmTlhAbR1s0KE= X-Google-Smtp-Source: ABdhPJwmbIkLzGrh5l1dr4IYZ38FsKo1NZaI3upf2u3749EYHuWaW8HOKtHI5OoH7VLO8T4LjsIrnw== X-Received: by 2002:a05:6402:520e:b0:428:22d0:e996 with SMTP id s14-20020a056402520e00b0042822d0e996mr9113042edd.250.1651777734313; Thu, 05 May 2022 12:08:54 -0700 (PDT) Received: from nijino.fritz.box (85-127-52-93.dsl.dynamic.surfer.at. [85.127.52.93]) by smtp.gmail.com with ESMTPSA id my14-20020a1709065a4e00b006f3ef214dc5sm1065630ejc.43.2022.05.05.12.08.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 May 2022 12:08:52 -0700 (PDT) Message-ID: Subject: Re: Multiple profiles with Guix Home From: Liliana Marie Prikler To: Maxime Devos , Andrew Tropin , guix-devel@gnu.org Date: Thu, 05 May 2022 21:08:51 +0200 In-Reply-To: <03221fd1743fb50325dff2604f7b4fc3ae450c1b.camel@telenet.be> References: <8735hqvh4a.fsf@trop.in> <8a42a0c84d35231b360a421fe0b846c8e1aa3d2c.camel@gmail.com> <8b66e609b7c9d5183017ccf7fef47c818fcea231.camel@gmail.com> <25e0ca9be4053c94d12461ec42f1985cd6730a8f.camel@gmail.com> <07907034239128b36890690703fe6cb6b4ce958e.camel@telenet.be> <53eabd93a0e41723ad3e0238314e630e713f8cfe.camel@gmail.com> <4bb446ca24b57f648d1dd4f0083010d9ee35c40f.camel@telenet.be> <28dcab6db488b73a95bfe349a3e97a3f4f5ec345.camel@telenet.be> <330265fe1014a4015dc64ec645f6c1171771b1df.camel@gmail.com> <03221fd1743fb50325dff2604f7b4fc3ae450c1b.camel@telenet.be> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=2a00:1450:4864:20::543; envelope-from=liliana.prikler@gmail.com; helo=mail-ed1-x543.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 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" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1651781075; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=J7/HLhQ22T0TRyQ6xRs0bnkJOSg4bE8QYrV4+US2DfM=; b=oPH92CmqcbuSirVGrfJjIu28A88bkQeh5bgP5SDfW8V9d7h2cbO2UeK/2QkyEcOCvhlgaj Y9y0v0I4sTZx99f6kPPbDAU5TcdHicGEjJFmyScIr1PT34Go4cHSk4U/E3O12KECsbaR/S X5sFmkdjL6oQ9WkGe27oflKQmg2vbxEpCeAMNVEbghwVYnmmXgXQbGRyMTazbACedxVyTl 18Q16uI8nLVYGEY1BRabi5Y9zwlyqRrDTJt9UiTH2aiTyOI5LeaLfPM7ejbTT1aJpJwqcA 1/mhTS8Y/2LT4t0SZUCjYlRrPMcDNhWsDhSR4dMZaX56pN/9H1COASzPzj8bcg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1651781075; a=rsa-sha256; cv=none; b=QaTuNWfXMqqg/Vyv8FsUkcEIT2/6dK5NP7m2PPnhcoouuvxVimQtDTFXPavJL0Nb7YwlP5 ogs36YFhknzrRuwoR8yMpHZzbK3THNxe7brkObvXGkhU7SsezgdfSW2ewrcMv5ajqcHz4M /6cwXPk0ACANNKcdXwBjkMFRQUue2R6LIewlDNeDhE4bcHgtleHNzXV+sBR7v7U5uxKy/J fob0wXIzQBJypLotZ0rVcWnF2w5BRnS9LltGxcAxtshLzmv93hdqNhmWyguuLoQjESM+cM pkUw3ES01Tsk8Bm33NbkMfi4oH/JoP1m0ZXHB/OdLfDZ7voo1qB4e5aoymLy1Q== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=VQGD1H1G; dmarc=pass (policy=none) header.from=gmail.com; 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" X-Migadu-Spam-Score: -4.43 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=VQGD1H1G; dmarc=pass (policy=none) header.from=gmail.com; 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" X-Migadu-Queue-Id: E4403291DE X-Spam-Score: -4.43 X-Migadu-Scanner: scn1.migadu.com X-TUID: aV36Yw7elEIT Am Donnerstag, dem 05.05.2022 um 20:00 +0200 schrieb Maxime Devos: > That's one method for faster builds, but you'll get even faster > builds by also making union-build O(n lg n) instead of O(n²), and the > latter optimisation will help everyone and not only Guix Home users. If that's what you want then go ahead and improve union-build. Unless you add some serious waste that eats up thousands of cycles if supplied with no more than three packages, I doubt it has any serious effect on my analysis that small n = better. As for the complexity of the actual implementation, I'm pretty sure you'll find it to be n log n in most cases, but I also fear that there might be degenerate cases in which the fact that we're reporting errors at all leads to a worst case lower bound of O(n²). > And the O(n)=O(1) doesn't seem quite right here to me -- individual > profiles will be smaller and hence faster, but there will also be > _more_ profiles.  Maybe if you sum over the profiles, you'll get to > O(n) instead of O(n²) (where n = number of store items in the > profiles) Again, k(n log n) <= nk log nk, for k >= 1. > But this doesn't take in account the _user_'s time cost of > having to figure out some kind of thematic split that doesn't break > search paths. And you're not taking into account my time cost of debating you when I already have manifests split across many files that I want to manage as separate profiles using Guix Home, kthxbye. But to entertain the idea, suppose Alice wants to make her profiles smaller so that they build faster. Which sounds more reasonable? Bundling groups of packages that fit together into their own manifests, then instantiating one profile for each, or rolling a six-sided die and putting the package into whichever bin is number four? If you're a machine, you probably think the latter. What could be more fair than a six-sided die? Why, a seven-sided die of course! > Or worse, if the user doesn't know what search paths are and when > they can break. > > Also, I still don't see the relation to > > > > I am not debating any legitimacy ( is not some > > > government), I am discussing the reasons, and whether some of the > > > features (e.g. faster profile building) can be implemented more > > > generally (not Guix Home-exclusive), without manual > > > configuration. > > > [...] > > -- I mention the phrase ‘faster profile building’ here, but I don't > think I'm implying here that faster build times cause tinier > profiles, or that tinier profiles don't help or such?  Is there some > specific phrase in that paragraph you disagree with?  Is there some > point you consider to be already addressed or not yet addressed or > some point you consider to not have to be addressed?  I don't know > what we are disagreeing about here? We disagree about the question whether users should be granted a method of declaring multiple profiles to use for their own purposes in whichever way they see fit through `guix home'. You are painfully trying to claim there is no need to do so whereas I not only claim there is, but also that any existing way of achieving similar results fails to meet my requirements, which are: 1. multiple profiles can be configured at once 2. profile locations should be specified by the user 3. profile generations are not littered, instead, the user has a way of linking to /var/guix/profiles/per-user 4. both package lists and manifests are supported 5. existing configurations can be expressed in terms of the new system 6. individual profiles can be "disabled", i.e. not sourced during activation, but still built 7. individual profiles can lack a manifest, in which case nothing is built, but they are still sourced on login With all of the above, home-profile-service would make most of the currently existing /etc/profile workarounds obsolete. The exception would be that /run/setuid-binaries is missing, along with any underspecified search path. For the latter we still need a solution that works regardless of guix home anyway, so it is not a point of discussion here. Cheers