On 6/28/23 17:06, Adam Williamson wrote:
On Wed, 2023-06-28 at 13:01 +0200, Ondřej Budai wrote:
I already answered you here:
https://pagure.io/fedora-workstation/issue/384#comment-862709
TL;DR: Let's figure this out when we are migrating other artifacts. For
now, the blueprint will be empty/minimal.
Thanks a lot for engaging with the feedback. However, I'm not convinced
by that answer, and I would prefer to follow up here; I suspect
feedback to an issue in the workstation tracker might well not be
captured in the Change process.
I think the points discussed in the ticket (layering/inheritance, and
package removals) are critical and they need an answer to be figured
out *before* we start switching Fedora live images to be built with a
different tool. I don't see how it can be good for Fedora if we have
*some* live images built with livemedia-creator and *some* live images
built with Image Builder - but if we start converting images without
figuring out what to do about layering and package exclusions, that's
exactly what we risk.
We do really kinda need inheritance to maintain the live image
definitions sensibly. (Also, a related point Neal didn't mention: we
share some elements of configuration between the live images and the
aarch64 disk images, since both are defined by kickstarts in the
fedora-kickstarts repo.) And we really need package exclusions to keep
some images to a sensible size.
We don't necessarily need these things to be completely implemented in
order to switch Workstation over, I don't think, but I think we should
at least have a *plan* for them. And ideally a timeframe.
Hey Adam (and Neal),
The good news is that the above *can* be done with `osbuild-composer`.
The bad news is that you can't do it in a blueprint.
Generally we have defined distributions in code, and all of the above
including sharing, exclusions, inheritance, can be done in those
definitions in code.
We are in the process of splitting those definitions out of our main
repository so pull requests and adjustments to those definitions are
easier and involve less knowledge of the project.
With that out of the way, I would much prefer if all of the above would
be achievable in blueprints.
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.
Taking from a bit further in the thread as well I currently have the
following list of attention items for *this* change proposal:
- sensible debug logs in koji
And for followup work to support spins, editions, other image formats:
- package exclusions in blueprints
- blueprint inheritance
Of those the first one clashes a bit with the principles of making it
hard(er) to break your image that osbuild-composer wants to follow but I
personally see no issue with handing people that footgun.
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).
Regards,
Simon
_______________________________________________
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
