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. 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. _______________________________________________ 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
