V Fri, Sep 10, 2021 at 02:26:20PM +0200, Petr Pisar napsal(a):
> I'm relieved to announce an availability of the new module packaging format,
> modulemd-packager, version 3.
>
[...]
> WHAT IS CHANGING
> ================
>
> Since there was no place for the contexts in the old module format, a new,
> input-only format "modulemd-packager", version 3, was designed and
implemented
> in MBS and other tools. At the opportunity of the format change, some other
> pet peeves of the old format were solved.
>
> Changes in the format include:
>
> New document type and version:
>
> document: modulemd-packager
> version: 3
>
[...]
> DNF handles outputs of both of them (the output format is distinguished with
> "static_context: true" field), but it behaves differently. With the old
> format, DNF can produce weird warnings or errors. Especially when your module
> is required by another module.
>
> Will the old format be supporterd forever? I don't know.
>
> Does have the new format some drawbacks?
A new drawback came out <
https://bugzilla.redhat.com/show_bug.cgi?id=2004853>:
Fedora 33 G.A. libmodulemd-2.9.4-3.fc33 does not yet support the new
static_context field. Because DNF strictly validates modules found in
repositories, libmodulemd will reject modules with the unknown field:
Module yaml error: Unexpected key in data: static_context [line 9 col 3]
and will ignore the module. That implies that DNF will handle packages of
those module builds as non-modular before checking an RPM transaction:
I really wonder how DNF is getting into this situation, because we
created the API with a `strict=False` option specifically for DNF.[1]
If they were reading the documents with that set appropriately, it
would be ignoring just the `static_context` attribute rather than the
entire document.
Though as I'm writing this, I did notice we have a copy-paste
mistake[2] in the documentation where we didn't set the value of
strict to False when talking about the DNF case, so that's perhaps
part of the reason. Sorry about that!
[1]