On Thu, Jun 29, 2023 at 1:06 AM Simon de Vlieger <cmdr@xxxxxxxxxxxx> wrote: > > On 6/28/23 22:32, Neal Gompa wrote: > > On Wed, Jun 28, 2023 at 4:26 PM Simon de Vlieger <cmdr@xxxxxxxxxxxx> wrote: > >> > >> On 6/28/23 21:12, Adam Williamson wrote: > >> > >>> The current Workstation live has the package exclusions from fedora- > >>> workstation-common.ks in it: > >>> > >>> https://pagure.io/fedora-kickstarts/blob/main/f/fedora-workstation-common.ks > >>> > >>> so it excludes three groups that are part of the 'standard' for live > >>> images but which Workstation doesn't want to include, and it excludes > >>> two packages that usually get pulled in as part of the installer > >>> environment. The reiserfs-utils exclusion could actually be dropped as > >>> we dropped reiserfs-utils from comps long ago, but the gfs2-utils > >>> exclusion is still 'active'. > >> > >> Thanks, yes I saw this when I ran ksflatten on it to come up with the > >> package set that was needed for the live installer that can be built by > >> osbuild-composer at this moment. > >> > >>> There is a bit of "defining base Fedora" - that's what fedora-live- > >>> base.ks does - but there is other stuff too. One very prevalent pattern > >>> is that we share a lot of stuff between live image and disk image > >>> definitions. So for e.g. for Workstation, we have these chains: > >>> > >>> fedora-live-workstation.ks inherits from fedora-live-base.ks and > >>> fedora-workstation-common.ks > >>> fedora-disk-workstation.ks inherits from fedora-disk-base.ks, fedora- > >>> disk-xbase.ks and fedora-workstation-common.ks > >>> > >>> so things that are 'basic' to each particular type of image are shared, > >>> but also things that are 'basic' to each edition or spin are shared, so > >>> we're not doing them twice between the lives and the disk images. > >>> > >>> Then we have things like labs/spins that are based on desktop > >>> spins/editions, but extend them. For e.g., the Design Suite lab is > >>> based on Workstation, so it inherits from fedora-live-workstation.ks . > >>> Astronomy_KDE and Scientific_KDE, obviously, inherit from the KDE > >>> kickstarts. > >>> > >>> There's also a 'minimization' pattern where several kickstarts inherit > >>> from fedora-live-minimization.ks , which does/did some shared > >>> minimization stuff. I kinda disliked that pattern and I've managed to > >>> pare that file down to just `-hplip` now, but that's still there as I > >>> haven't managed to shift it. > >>> > >>> So, there's a lot going on with the inheritance stuff. :D It definitely > >>> needs to be evaluated at least. You can just do `grep include *.ks` in > >>> the fedora-kickstarts repo to get a feel for everything. > >> > >> Thanks for that write up, I'm going to go spelunking in this repository > >> and come up with a plan on how to support an approach like this to > >> define editions/spins in blueprints so there's no wall in front of us > >> for future building of those images as well. > >> > >> I can see it hopefully becoming *easier* to define spins, editions, and > >> remixes of Fedora in the future. > >> > > > > Comparatively, the Fedora Asahi Remix is defined using KIWI > > descriptions using composition and inheritance of profiles and config > > snippets. > > > > Top level file: > > https://pagure.io/fedora-asahi/kiwi-descriptions/blob/rawhide/f/config.xml > > > > Desktop environment fragment: > > https://pagure.io/fedora-asahi/kiwi-descriptions/blob/rawhide/f/components/desktop-environments.xml > > Common packages: > > https://pagure.io/fedora-asahi/kiwi-descriptions/blob/rawhide/f/components/base.xml > > Boot packages: https://pagure.io/fedora-asahi/kiwi-descriptions/blob/rawhide/f/components/boot.xml > > Workstation platform: > > https://pagure.io/fedora-asahi/kiwi-descriptions/blob/rawhide/f/platforms/workstation.xml > > > > I would say personally that not being able to do this is a blocker for > > adopting osbuild-composer blueprints. > > Thank you Neal. Is there a reason why Fedora Asahi does not use the > kickstart system? If so it'd be nice if we can support that use case as > well in osbuild-composer :) > > I'll take the kiwi example files (and the kickstarts) in mind to work on > a direction for blueprints to take to support these usecases. > I wouldn't subject my worst enemies to Oz and ImageFactory (which is what we use for Cloud images). And since Lorax (which is what we use for live and ARM images) requires Anaconda to understand the target system to install, it couldn't be used for creating these images either because that requires teaching Anaconda about Apple Silicon Macs. And reintroducing appliance-tools for Fedora images might make some people upset. :) As for why kiwi? I understand it quite well, and the kiwi team has been extremely receptive to community needs above and beyond virtually any other team I've worked with ever. I became a member of that team a few years ago too. And there is Koji integration for kiwi, which means that it can be (eventually) integrated into the Fedora compose process. Fedora Cloud is also looking into kiwi too[1]. The objections brought up about the blueprints in this Change also apply to any potential Fedora Cloud adoption of osbuild-composer infrastructure[1]. We need that solved to adopt it there too. [1]: https://pagure.io/cloud-sig/issue/407 -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
