Oh, and one more: the bootable property is set false, it should be true. (I don't know of anything that reads this, but hey, let's be correct).

This needs changes directly in Pungi. It now sets the location and bootable property with no option to change it from the configuration.
Deciding between iso/ and images/ directories seems easy, but how can bootability be detected?

How do we do it for the existing live images?

Those are all bootable. All phases hardcode some value for all produced images, with the exception of DVDs, where Pungi is actually creating them and thus knows what the result is. For anything created by a dedicated Koji task, there's a default value.

Kiwi does not produce non-bootable ISOs (at least not intentionally).

Insofar as the type goes, @kevin and I figured out that pungi was propagating the kiwi image build type into the the pungi type data, so I sent a PR to productmd to recognize it. If we don't want to do that, then we need some way of telling pungi what type it is without breaking kiwibuild.

Perhaps one way to resolve this is to rename type for kiwibuild to build_type and use type for the pungi/productmd type? That would still require teaching productmd that live produces iso files, but that would probably work better anyway, since kiwi's types don't make sense from a "productmd" perspective.

https://osinside.github.io/kiwi/image_types_and_results.html

Kiwi does not produce non-bootable ISOs (at least not intentionally).

That's good to know. We could do this: https://pagure.io/pungi/pull-request/1782
If it's an ISO, it's bootable and goes to iso/.
Otherwise, put it to images/ and list as not-bootable.

The kiwi documentation suggests that any ISO is going to be of the live variety. If it can't do netinst or dvd, we could simply default to live for any ISO produced by kiwi.

kiwi can produce what are known as "installisos" for the oem type, such that it will produce both a disk image and a wrapper iso file that will contain a simple installer to flash the image from a usb stick or dvd to a disk. So it is possible to have non-live ISO files.

Information here: https://osinside.github.io/kiwi/building_images/build_expandable_disk.html

I have also been looking into producing netinst ISOs with kiwi, though that is a bit further away from right now, and it is possible to produce install dvds if you have a way to merge an offline repo and its configuration into a netinst ISO. So I don't necessarily want to assume that in the future we won't make those too.

I believe merging Neal's productmd PR was wrong. It is not correct for any image to have iso as its "type". We should not accept kiwi doing that, we should fix the kiwi pipeline so that does not happen. The types need to be correct.

I don't really care about the details of how that is managed between kiwi and pungi and koji, but I'm going to be pretty firm about the end result: official live ISOs need to have type live and format iso, and should be bootable true. It's not acceptable to break productmd's expectations to make life convenient for kiwi, doing that makes it pointless to have metadata in the first place.

For bonus points the mechanism should be flexible enough that we can potentially also do a live ISO with a special type like live-kiwi, as we do for osbuild with live-osbuild; this makes it easier to consider moving existing live images to be built with Kiwi as it allows for a transition period where we build the image with both tools for a while, until we're confident the image built with Kiwi is good enough to usurp the existing image and take the live type. Adding types like that to productmd is legitimate IMO.

Then pungi needs to change to decouple kiwi's build types from product types.

To illustrate why we have the difference between "format" and "type", consider that we have both a Server DVD ISO and a Server network install ISO, and a Workstation live ISO and a Workstation network install ISO. The "type" concept is what differentiates between these. If we just called them all "ISO" you could not programatically distinguish between those pairs without parsing the filename, and avoiding having to do that is the point of having metadata.

It's acceptable for type and format to be the same for an image if the format effectively defines the type - you couldn't have another image of the same format but a different type. This is clearly not the case for the ISO format. (So far I don't think we've ever had two images with the same type but different formats, but it does seem at least conceptually possible. For the Cloud images, instead of having matching types and formats, we could have used the same 'type' for them all, but different formats. To me that would have been conceptually correct, since they are all disk images intended for deployment to clouds. Arguably this would be better - take the tar-gz "type", which indicates a cloud image for Google Compute Engine, it is very obviously the case that we could potentially wind up with some other image with a .tar.gz extension which is not a GCE image, at which point we have a problem.)

https://pagure.io/pungi/pull-request/1782 is updated to make it possible to set the desired type explicitly in the config file. The osbuild phase already has this functionality, so there's some precedent for naming.

Commit d9d21d3c relates to this ticket

lsedlar also built the pungi fix as 4.7.0-3 - thanks. Updates are available for all releases - https://bodhi.fedoraproject.org/updates/?packages=pungi .

https://pagure.io/pungi-fedora/pull-request/1338 and https://bodhi.fedoraproject.org/updates/FEDORA-2024-8003545aeb are the outstanding bits now, AIUI, to apply the fix to F41. But I think we can close this as the images are only enabled at all in Rawhide ATM, and Rawhide is fixed.