From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on atuin.qyliss.net X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 Received: from atuin.qyliss.net (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id C3728615C0; Thu, 15 Sep 2022 12:32:33 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 496) id 4EF4D61676; Thu, 15 Sep 2022 12:32:31 +0000 (UTC) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) by atuin.qyliss.net (Postfix) with ESMTPS id 5662561674 for ; Thu, 15 Sep 2022 12:32:27 +0000 (UTC) Received: by mail-ed1-x52e.google.com with SMTP id e18so26742761edj.3 for ; Thu, 15 Sep 2022 05:32:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unikie.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=OoRL7AzPIEr7Xu9pndbD8OE59bupbnhrJeubfSP1UH8=; b=WHyHRtcxeBLc1SaJkLt4VqicHvVInWwttWHuNiwxTWUhNM8C6/rGLazQz/YBtssnER syVSM0KLhGNEXPG0Ry2Aj3RIrghlVbge1H1omTv7i55wlayp7+yWWzVQZ/8W5E9Iv1dM pqWRU+2RZRJm09QroXXnMTO//ShOG0iYPFJQ0P1cflhPVfEdyrmNhA1ef/peTSEDQnLC YrXBGVt/aL6jJjnALqSU0S0T7V79B4Zue+/rIhGm26bYeQx9AnLjAlJomXFkckEhsFne OZdGEM3m3fgN1tlT9CKolV4aqPq/dWYd3+1L2USXHKboMrz+7LMIQB5NPXULZaPHZpq3 /dtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=OoRL7AzPIEr7Xu9pndbD8OE59bupbnhrJeubfSP1UH8=; b=mAFhiQrhmp88VqLWJLwgpJxvgD/+xHc80wtA593KBAy5It7L34N9sX+O+tdTw7Uz+Z zzqL1I5TuO69XBBNah5BHp9WT9dswstTEhPrReD+afbM6oaLMRFUsJWoHTsvwVcuNpZi 1gdEf5nT1gyFvo80iIcm6MjZcMcPNGCTCd4+g1iusQKBge7+b/hyBCDJRk8+KomQ3SrX 8tui8fJ4CLQkFCa5uH8rhGmmuvPF786k0BBRxv5q0XfkNIecZRdydW+XSA4PudtDcLJg XmDD1SI6XKwyMc3RGtjzTz8KktGYmYNX0pUZODfksP9Y7pCfnFCcFk42nW1mILDQ5Hk6 GLyg== X-Gm-Message-State: ACgBeo3U4a71bi5YIfuzf5A88LIPW9rJQwU8l1vzeAUo3gSTNB6Koumw fh9ec2Js0d/loStahHKGmd2oRYGVwTHCgyf46Wcp1A== X-Google-Smtp-Source: AA6agR7rNitFdcMiJPSEdppVLdrEVpND9Wghw66PlO25NJG7+0Os4ok5UuuVK8F4/T4zf4rksmTmeoWbgPNQ27bN9Y4= X-Received: by 2002:a05:6402:3509:b0:452:20c7:5a95 with SMTP id b9-20020a056402350900b0045220c75a95mr14057681edd.427.1663245144745; Thu, 15 Sep 2022 05:32:24 -0700 (PDT) MIME-Version: 1.0 References: <20220915073515.47855-1-jose.pekkarinen@unikie.com> <87mtb1xd38.fsf@alyssa.is> <87h718yiuk.fsf@alyssa.is> In-Reply-To: <87h718yiuk.fsf@alyssa.is> From: =?UTF-8?Q?Jos=C3=A9_Pekkarinen?= Date: Thu, 15 Sep 2022 15:31:48 +0300 Message-ID: Subject: Re: [PATCH] Add image configuration option To: Alyssa Ross Content-Type: multipart/alternative; boundary="00000000000006fc5d05e8b670da" Message-ID-Hash: WTZXBOBQ3SXKJTF3XE3BZA2HDQODFLGE X-Message-ID-Hash: WTZXBOBQ3SXKJTF3XE3BZA2HDQODFLGE X-MailFrom: jose.pekkarinen@unikie.com X-Mailman-Rule-Hits: header-match-devel.spectrum-os.org-0 X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-config-1 CC: devel@spectrum-os.org X-Mailman-Version: 3.3.5 Precedence: list List-Id: Patches and low-level development discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000006fc5d05e8b670da Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 15, 2022 at 2:31 PM Alyssa Ross wrote: > [...] > Okay, thanks for the explanation. I think we can group some of these > together: > > =E2=80=A2 Stuff that's already Nixpkgs configuration options or can be > expressed through an overlay. Whether to cross compile, what > architecture to build for, whether to use a vendor kernel, etc. This > can already be handled through the existing configuration mechanism. > > =E2=80=A2 VM customisation, including extra VMs, disabling Wayland, etc.= In my > mind there are still some open questions around how this should be > implemented exactly, but this is definitely something that needs to > be more configurable. > > =E2=80=A2 Whether to install extra stuff on the host system. This cover= s > things like debugging symbols and tools. > > Does that sound right to you? Are there more that you can think of? > I'd like to understand the requirements here better, to help think about > what sort of configuration mechanisms might be required. > This is a good summary, currently I can think of a coupel of more, which is a mechanism to provide upstream project configuration artifacts when nix allow to bypass their automated configs, for example, a kernel config when using manual config kernel nix package, a bit more unclear is how to provide upstream configs when nix is not flexible enough. A mechanism to generate a full image from the nix generated artifacts putting together kernel, initrd, rootfs and ext partition so that the full image ca= n be flashed in a sdcard of choice and use it. This would require to be configurable so that you can modify the partition table to suit vendor needs. [...] > You're right =E2=80=94 it's generally a bad thing if people have to patch > Spectrum to make it fit their needs. I want to avoid that. But most of > the things we've talked about so far don't feel to me like they're going > to lead to massive configuration files. The exception is all the stuff > that's either Nixpkgs configuration or overlays, but the mechanism you > proposed here wouldn't help with that, because only a single > configuration file would be able to change anything in "pkgs", due to > the configuration files being merged using the non-recursive // > operator. That's exactly why it's important to understand what the > needs are before we consider specific configuration mechanisms. It's > difficult to figure out if an idea will actually make things easier > without seeing an example of the problem, and what difference to it the > proposed solution would make. > Well, the exact point of that is to give you a small next step to move towards a more flexible configuration system, without loosing control to revert back if the situation doesn't look better. It is unlikely a more complex contribution would be acceptable for you if even a little one like this wouldn't make it. Jos=C3=A9. --00000000000006fc5d05e8b670da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Sep 15, 2022 at 2:31 PM Alyss= a Ross <hi@alyssa.is> wrote:
[.= ..]
Okay, thanks for the explanation.=C2=A0 I think we can group some of these<= br> together:

=C2=A0=E2=80=A2 Stuff that's already Nixpkgs configuration options or c= an be
=C2=A0 =C2=A0expressed through an overlay.=C2=A0 Whether to cross compile, = what
=C2=A0 =C2=A0architecture to build for, whether to use a vendor kernel, etc= .=C2=A0 This
=C2=A0 =C2=A0can already be handled through the existing configuration mech= anism.

=C2=A0=E2=80=A2 VM customisation, including extra VMs, disabling Wayland, e= tc.=C2=A0 In my
=C2=A0 =C2=A0mind there are still some open questions around how this shoul= d be
=C2=A0 =C2=A0implemented exactly, but this is definitely something that nee= ds to
=C2=A0 =C2=A0be more configurable.

=C2=A0=E2=80=A2 Whether to install extra stuff on the host system.=C2=A0 Th= is covers
=C2=A0 =C2=A0things like debugging symbols and tools.

Does that sound right to you?=C2=A0 Are there more that you can think of? I'd like to understand the requirements here better, to help think abou= t
what sort of configuration mechanisms might be required.

which is a mechanis= m to provide upstream project configuration artifacts
when nix allow to= bypass their automated configs, for example, a kernel
config whe= n using manual config kernel nix package, a bit more unclear
is h= ow to provide upstream configs when nix is not flexible enough. A
mechanism to generate a full image from the nix generated artifacts puttin= g
together kernel, initrd, rootfs and ext partition so that the f= ull image can
be flashed in a sdcard of choice and use it. This w= ould require to be
configurable so that you can modify the partit= ion table to suit vendor needs.

[...]
You're right =E2=80=94 it's generally a bad thing if peopl= e have to patch
Spectrum to make it fit their needs.=C2=A0 I want to avoid that.=C2=A0 But = most of
the things we've talked about so far don't feel to me like they'= ;re going
to lead to massive configuration files.=C2=A0 The exception is all the stuf= f
that's either Nixpkgs configuration or overlays, but the mechanism you<= br> proposed here wouldn't help with that, because only a single
configuration file would be able to change anything in "pkgs", du= e to
the configuration files being merged using the non-recursive //
operator.=C2=A0 That's exactly why it's important to understand wha= t the
needs are before we consider specific configuration mechanisms.=C2=A0 It= 9;s
difficult to figure out if an idea will actually make things easier
without seeing an example of the problem, and what difference to it the
proposed solution would make.

Well, the exact point = of that is to give you a small next step to move
towards a more flexible configuration system, without loosing controlto revert back if the situation doesn't look better. It is unlikely = a more
complex contribution would be acceptable for you if even a= little one
like this wouldn't make it.
Jos=C3=A9.
--00000000000006fc5d05e8b670da--