On Wed, Jul 4, 2018 at 7:38 AM Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > > On Wed, Jun 20, 2018 at 02:20:59PM -0400, Stephen Gallagher wrote: > > It also carries with it the implication that the supported package managers > > must handle module updates correctly. (It does *not* require that they all > > be able to handle selecting/switching module streams, but it must honor > > whichever stream was set via DNF). > > I expect that getting support in all the package managers is the hard part. > I'm happy to see this explicitly stated in the Change page and included in > the Contingency section. > > What package managements softwares need to be updated apart from packagekit? Since we're ignoring YUM, the main issue at this point is that modulemd isn't understood by libsolv, so handling of modules is very strange. > What is the current status of those changes? With DNF 3.x, libmodulemd is used through gi for the python frontend. With libdnf 0.15.x, libmodulemd is linked in and we're forced to do our own depsolving for modules, because the solver doesn't know anything about them. That said, my understanding is that the repodata format is still kind of up in the air, so until the module repodata format is rationalized to be sane w.r.t. rpm-md, then I suspect this will not get fixed. No one I've talked to is particularly enthused with the idea of having YAML parsing for repodata, because of how insane YAML tends to be. And libsolv is intended to be mostly self-contained, so it has its own internal representation of rpm-md, comps, etc. YAML as input is fine, but we're more comfortable with the idea of the output being XML so we can keep using the same validated XML parser for everything. Multiple parsers make things much harder... Incidentally, one of the reasons why PackageKit doesn't understand comps anymore is because libdnf hasn't transitioned to using libsolv for comps processing yet. That's something that's coming eventually, and with it will be a simpler API for dealing with comps groups. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/2HMTVKL5CE7QMDLHC77KEQXUFF4DJBFV/
