adamwill commented on the pull-request: `osbuild: build workstation` that you are
following:
``
In terms of what the metadata for these images should actually *be*, I don't think
they should have identical subvariant, type and format to the images built with a
different tool, as that's confusing. In fact, now I recall, the productmd docs
[specifically say you can't do
that](https://github.com/release-engineering/productmd/blob/master/doc/im...:
"It is required that the combination of subvariant, type, format, arch and
disc_number attributes is unique to each image in the compose."
...and there is a [function that identifies images according to those
properties](https://github.com/release-engineering/productmd/blob/master/....
Also, there's [a
check](https://github.com/release-engineering/productmd/blob/master/produ...
which I think might cause composes to blow up if you actually *do* manage to cause an
image to have the same identifying properties as an existing image (assuming the compose
process runs through that function, which I think it does).
As the image types are [defined in
productmd](https://github.com/release-engineering/productmd/blob/master/p...,
we can't just make up new ones for these images, and we shouldn't really
'abuse' existing types to mean something other than they're meant to (as
we're currently doing here). Probably the easiest thing to do would be to give these
images different subvariants, however we need to express that in Pungi config (or
whatever). So the IoT installer image built by osbuild could be subvariant
"IoT-osbuild", type "dvd-ostree".
``
To reply, visit the link below or just reply to this email
https://pagure.io/pungi-fedora/pull-request/1190