compose: Initial kickstart support

[cgwalters]

The treefile syntax is...ok, but it is bespoke to us and we never really emphasized its use outside of our sphere.

As I'm looking at https://gitlab.com/fedora/bootc/tracker/-/issues/32 I'd really like to expose something that has existing widespread use as a default entrypoint.

kickstart is really old, long predating even virtualization.

It has a decent set of features (includes, comments) as a baseline specifically as a mechanism to define package sets, it has key features we want:

• turning off weak dependencies
• excludes

This is just a stub kickstart parser...the next step is to wire this up into the treefile.

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[cgwalters]

OK, moving this one out of draft...I think it works enough to demonstrate the idea.

Opinions?

[jmarrero]

this looks ok to me, I personally would love if we could move people to the treefile instead of us adopting kickstart. For me yaml is so much nicer and feels modern vs kickstarts but I understand that ks is understood and wildly used in the RH/CentOS/Fedora universe and might be what people expect to use to build their images.

[jmarrero]

lgtm

[jmpolom]

This was already merged however from a user who has fought with both kickstart (in anaconda) and the treefile format, I'm concerned how this improves the experience of building custom ostree images. I'm also concerned about the introduction of a new parser within bootc to handle the ks format. Seems like this should be modularized out into a separate crate which can independently developed, tested and validated. The support is so barebones (vs what kickstart supports in anaconda and vs what treefile supports) I question what benefits this will have for those of us composing custom images.

Edit: to be more helpful with my feedback, supporting pre and post scripts is probably an essential feature for this to be even minimally viable for most use cases I can think of. A downside of kickstart is I don't think it has a way to direct inclusion of a specific file into the resulting installation root fs. I do think whatever format is used to define ostree images should have a very easy way to drop in files into the resulting ostree root fs from within a directory structure that exists alongside the configuration information (kickstart/treefile whatever). Treefile does this today with add-files but it only will pull in files at the same level as the treefile which makes it obnoxious to use.

[cgwalters]

Hi @jmpolom, thanks for your feedback. The target for this is just the package configuration.

. I'm also concerned about the introduction of a new parser within bootc

This project is rpm-ostree, not bootc. The bootc project is agnostic to the input build system.

to handle the ks format. Seems like this should be modularized out into a separate crate which can independently developed, tested and validated.

Yep definitely.

Edit: to be more helpful with my feedback, supporting pre and post scripts is probably an essential feature for this to be even minimally viable for most use cases I can think of.

In practice the goal of this is just to be a declarative package input; we wouldn't require all executable code to be done via kickstart.