V Wed, Dec 07, 2022 at 04:31:36PM -0500, Stephen Gallagher napsal(a): > On Wed, Dec 7, 2022 at 8:40 AM Petr Pisar <ppisar@xxxxxxxxxx> wrote: > ... > > As you can see, there are no separate documents for modules and default > > streams. Everything is kept inside one document. That enables > > properties (e.g. obsoletes or default profiles) pertaining the same entity > > (e.g. a stream) to be placed together. That prevents from repeating the > > identifiers (e.g. stream names) and makes the format more succinct and easier > > for querying. > > To provide a bit of context here: the output format containing all of > the modules, streams and defaults together makes perfect sense. Please > make sure to keep in mind that the input format still needs to > recognize at least some of these differences. The reason is that the > default stream must be specified on a per-distribution/release basis. > Its input file has to therefore be independent from the module stream > definition. Initially, the modulemd design had both default streams > and default profiles specified as content that was to be managed by > the distribution, rather than the module maintainer. We later realized > that the default profile selection should be left up to that stream's > maintainer. Unfortunately, our output format still maintained it as > part of the modulemd-defaults document. This is part of why we created > the modulemd-packager format. This format enabled maintainers to > specify their preferred stream defaults in the packager document and > the result would be output that translated that into the > modulemd-defaults format. > > If we're going the route of entirely replacing the output format, then > this is definitely a place we can improve upon. But please keep the > default stream selection independent from the stream definition. > Thanks for explaining the reasons behind the YAML fromat design. Now I do not plan changing the input YAML format. The output XML is capable to deliver definitions of default streams independently of module build definitions: <index xmlns="http://fedoraproject.org/metadata/moduleindex"; version="1" revision="0"> <module name="perl"> <default-stream modified="202205040810" stream="5.34"/> </module> </index> When DNF will see a document like that it will know that a default perl stream is 5.34. It does not imply that there is a perl module build for installation or even presentation in "dnf module list" command. The default profile can be similarly encoded like that: <index xmlns="http://fedoraproject.org/metadata/moduleindex"; version="1" revision="0"> <module name="perl"> <stream name="5.26"> <default-profile modified="202205040810"> <profile>default</profile> </default-profile> </stream> </module> </index> If a module maintainer specified a default profile in modulemd-packager document, it would be encoded in XML like this: <index xmlns="http://fedoraproject.org/metadata/moduleindex"; version="1" revision="0"> <module name="perl"> <stream name="5.26"> <build version="3720220503131308" ...> ... </build> <default-profile modified="20220503131308"> <profile>default</profile> </default-profile> </stream> </module> </index> This is similar how MBS is supposed to produce YAML output documents. (I write supposed because MBS does not implement this feature yet.) > Regarding glib: it was chosen entirely because DNF (at the time) was > using already using it, so it would theoretically simplify the > consumption of libmodulemd. If DNF5 has moved away from glib, I don't > see any reason why libmodulemd couldn't do the same. However, since > DNF isn't the only consumer of libmodulemd, I'd very much like to see > this new parser implementation made available as an external library > with a public API that DNF5 consumes, rather than as an internal > detail of DNF. While I understand (and even like) that XML gives you > syntax validation capabilities, libmodulemd was also capable of > recognizing logical errors (such as specifying a default profile that > doesn't exist in the stream). A library that can provide such > hand-holding would be very valuable to anyone who intends to consume > the new format. The API can also guide the consumer to the data they > care about, rather than forcing them to parse the XML directly. Yes, the XML parser will be a separate library from libmodulemd library. Regarding validator, there probably will be a validating tool for the XML format. I'm aware that XML Schema is unable to grasp all contrains and recommendations and that for users it's easier to execute a dedicated tool than invoke xmllint with a path to the schema burried somewhere deep in a file system. -- Petr
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
