On Wed, 2023-06-28 at 18:44 +0200, Simon de Vlieger wrote: > > What I would like to know is what is the minimum customizations needed > in blueprints for this change proposal and what is necessary for > supporting editions and spins down the line. Thanks, Simon. So, we obviously don't need layering/inheritance *implemented* to build a single live image. I'm not saying we do, just that we need a plan to address the need that is currently addressed by kickstart inheritance. 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'. > > The second one is likely harder but seems to be based very much on > 'thats how we do it now'. Personally I'd prefer having base fedora > defined in code and each edition/spin being a small blueprint that only > adds onto that base Fedora. That way spins would be less affected by > changes in inherited kickstarts/blueprints. > > I'll dive into the kickstart repository to see what exactly is being > done but it's likely that a lot of what happens in kickstarts currently > already happens in code in osbuild-composer (e.g. adjustments to > bootloaders/partitions/extra packages to install based on the output > image type and architecture). It's not really, or not entirely, about either of those. Ensuring all bootloader packages is present is really handled by comps - they are in the anaconda-tools group, and we always pull that into live images (it's in fedora-live-base.ks ). 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. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@xxxxxxxxxxxxx https://www.happyassassin.net _______________________________________________ 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
