Check for *_LIKE properties in os-release if def file is not found

[MoralCode]

I've been building a downstream image based on fedora 40 and, by changing the ID of my system, i now get this error when trying to build an anaconda iso.

bootc-image-builder/bib/internal/distrodef/distrodef.go

Line 61 in cfb33fd

return "", fmt.Errorf("could not find def file for distro %s-%s", distro, wantedVerStr)

as suggested on matrix, I have added the ID_LIKE field to my os-release file, and I think it would be helpful for bib to be able to check this during its process of trying to find a compatible def file for the OS.

I strongly suspect this will make the process of creating derived images far easier. If this is something thats a desireable fix and a "good first issue" type of thing, I could maybe take a shot at an implementation

[mvo5]

Thanks for reporting this issue - for context, could you please attach or paste the /etc/os-release ?

We can/could implement the ID_LIKE fallback, the only complication is that our current code will not use distro definitions for older distros, e.g. if we have a "fedora-40" distro def but are asked to build a fedora-38 iso this will fail. The reasoning is mostly that old versions of the distro may not have the packages yet that the distr-definition has. So far this is fine, but for "remixes" that declare they are like "fedora" but are on VERSION=7 this will become a problem. We could relax the rules but it would be nice to learn more about the typcial os-releae here.

Alternatively we could just add a bunch of symlinks for known derrivates (which of course does not scale very well :/)

[MoralCode]

i havent looked into it too closely, but it feels to me like *_LIKE could be reusable (if it wasnt designed that way) as a generic convention, so maybe the os-release could define VERSION_LIKE as well (in case the downstream image is based on, i.e. Fedora 40, but chooses to use its own versioning convention, but if not present would just default to VERSION maybe?)

heres my os-release: https://gitlab.com/RITlug/TigerOS/server/image/-/blob/main/os-release?ref_type=heads

Ultimately i was thinking that fixing this issue would be primarily be useful to people building new images on top of fedora bootc images with versions 40 or higher, especially as bootc adoption grows, so i would expect this system to throw a similar error to what it does today if no def is present for either the ID + VERSION or ID_LIKE + VERSION_LIKE

[mvo5]

Having ID_LIKE + VERSION_LIKE would be ideal, if that is available it could be (relatively) easily added.

AIUI VERSION_LIKE is not an official key though (not part of the os-release man page) - is it already used (pardon my ignorance on this)? If so I can look into adding this.

[cgwalters]

There's a few things going on here, but I think the biggest is https://docs.fedoraproject.org/en-US/bootc/os-release-and-versions/

And yes today there is nothing like VERSION_LIKE. There's a deeper thing going on here that OCI is all about multi-layer derivation but the UAPI/systemd side doesn't see things that way and basically encourages sysext-style things on top of a single base.

I think where things start to get a little complex is that of course one can trivially have three or more layers, and that's actually a reasonable thing to do sometimes! (think "fedora", "platform team", "app team"). But probably in most cases the "platform team" can own the version and "app team"'s version and metadata would show up somewhere else (e.g. in application images).

It's probably worth trying to standardize VERSION_LIKE. In the interim we could make up one.

---

That said there's a different fix here which is basically...bib IMO should aim to stop including operating system dependent sets of packages inside itself and fetch them from the OS instead. For example, we already have the lists of requirements for installing anaconda in the anaconda.rpm metadata and I just don't understand why we replicate them here.

I have to emphasize the importance of this point because it naturally means that anyone who wants to configure/override things can do so by changing the dnf repos which is already a well known operation. And note today the "base os version" mapping here already goes by a well known channel in the releasever metadata in the -release package. (Which of course, overlaps with os-release but that's its own topic)

[achilleas-k]

That said there's a different fix here which is basically...bib IMO should aim to stop including operating system dependent sets of packages inside itself and fetch them from the OS instead. For example, we already have the lists of requirements for installing anaconda in the anaconda.rpm metadata and I just don't understand why we replicate them here.

I have to emphasize the importance of this point because it naturally means that anyone who wants to configure/override things can do so by changing the dnf repos which is already a well known operation. And note today the "base os version" mapping here already goes by a well known channel in the releasever metadata in the -release package. (Which of course, overlaps with os-release but that's its own topic)

You mean we should just install anaconda and all recommended dependencies and call it a day? I suspect there might be more to it than that, but we can try.

We still need to install build packages to create the ISO and some of those have distro-dependent names. Though this might not be true of the build packages for Anaconda in particular, so I'd have to look.