README.md: A few tweaks

[cgwalters]

• Clarify functionality
• Link to centos-bootc
• Use new image reference
• Target c9s because ELN is more aggressive and has bugs

[cgwalters]

Ah yes, switching to c9s is going to be a problem because of the hardcoded uefi vendor stuff:

  "uefi": {
    "vendor": "fedora",
    "install": true,
    "unified": true
  },

Which gets into the bootupd handling, which in turn gets into using bootc install.

[cgwalters]

which in turn gets into using bootc install.

We're going to need to have a real debate about this soon because it's quite important.

[achilleas-k]

Ah yes, switching to c9s is going to be a problem because of the hardcoded uefi vendor stuff

Let's pull all that out into a config then. Build-root repos are already externally defined but embedded at compile time. We can do the same so that the binary is self contained or keep a config with some strings in the repo.

[teg]

Sounds like the kind of stuff that should be declared in the container metadata? at least if it declares the distro, we can have a mapping (as I believe we do) from distro to things like UEFI vendor.

[vrothberg]

LGTM

[cgwalters]

Sounds like the kind of stuff that should be declared in the container metadata? at least if it declares the distro, we can have a mapping (as I believe we do) from distro to things like UEFI vendor.

Yes, in theory we could do that. But this also leads to #18

where bootupd basically handles this dynamically. Now in theory of course we could change the osbuild bootloader code to do the same; I actually don't understand why the vendor is hardcoded instead of being detected today.

[ondrejbudai]

What about splitting this PR? I'm happy to make explicit in the README.md that this is paired with centos-bootc.

However, we are not ready to make the centos container the default experience, we still have some issues with them, see #20. Note that @mvo5 is working on a short-term fix for this, before we can fully switch to bootc.

[cgwalters]

This is obsolete.