Since rpm-ostree is all about tight integration with the Fedora/CentOS/RHEL ecosystem, we should consider supporting kickstart files as input.
Conceptually, there's a lot of overlap in the core components of "package list" + "%post". Now obviously, some things like partitioning don't apply at all. (Or do they? Should we support embedding a default kickstart into the tree to be used by anaconda?)
Besides that, there are a lot of kickstart verbs for configuration (timezone, rootpw, firewall) that could theoretically apply for people who want to make site-specific tree commits (as opposed to generic OS vendor trees). However, if we wanted to support that we'd basically have to carry over a lot of logic from Anaconda.
So my feeling on that is that at least initially, the "embed KS in tree to be processed once by Anaconda" model would be useful and nice. However, that would be confusing as then only the %packages and %post sections would have "anti-hysteresis".
czadikem
commented
1 year ago
Since rpm-ostree is all about tight integration with the Fedora/CentOS/RHEL ecosystem, we should consider supporting kickstart files as input.
Conceptually, there's a lot of overlap in the core components of "package list" + "%post". Now obviously, some things like partitioning don't apply at all. (Or do they? Should we support embedding a default kickstart into the tree to be used by anaconda?)
Besides that, there are a lot of kickstart verbs for configuration (
timezone,rootpw,firewall) that could theoretically apply for people who want to make site-specific tree commits (as opposed to generic OS vendor trees). However, if we wanted to support that we'd basically have to carry over a lot of logic from Anaconda. So my feeling on that is that at least initially, the "embed KS in tree to be processed once by Anaconda" model would be useful and nice. However, that would be confusing as then only the%packagesand%postsections would have "anti-hysteresis".