On Fri, Oct 16, 2026 at 4:30 AM Petr Pisar via devel <[email protected]> wrote: > > V Thu, Oct 15, 2026 at 10:31:06AM -0700, Kevin Fenzi napsal(a): > > I am not a change owner/dnf5 maintainer here, so it's likely up to them > > what to do about this, but I wonder if it might be possible to keep > > libmodulemd and move the modularity handling off to a dnf5 plugin that > > uses it. Then you / interested parties could maintain libmodulemd and > > that plugin and largely not impact other things? > > > While technically possible, from user's point of view it would be > a degradation: Users want to see modularity-specific error messages when > modularity prevents from using the packages. That requires a special type of > error on DNF5 level. That means that DNF5 would need to carry a special type > because of a plugin. That would be technically wrong. Of course one could > extend DNF5 interface with some kind of dynamic types but that level of > abstraction would have its penalty (maintenability, speed, transparency). I'd > rather not doing it just because of modularity. >
There was already a request for an API to allow plugins to propagate errors like that for other things (pulling out bootc/rpm-ostree code, the txnupd plugin, etc.). It seems like it would make sense to deal with all of those at the same time. -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
