#147 Warn the user somehow when dependencies are resolved against non-api package
Opened 13 days ago by bookwar. Modified 8 days ago

In https://pagure.io/modularity/issue/146 we propose the policy that non-api packages shouldn't be allowed in default streams.

But for enabled non-default streams we still have a similar problem: from the user point of view there is no visible difference between api and non-api packages provided by the module. Thus, it might be that user will accidentally resolve a certain dependency against non-api package of the module enabled on the system.

Proposal:

  • add a warning (fail?) if installation of a non-api package is requested through dnf

  • add a warning, or even fail dnf dependency resolution if package outside of a module is resolved against non-api package of the module


Proposal:

add a warning (fail?) if installation of a non-api package is requested through dnf

I assume you mean "requested explicitly", not as a dependency. I could see us providing such a warning in that case.

We might also have an interactive DNF section similar to how we show the modules being enabled, "skipping packages with broken dependencies", etc. that shows that some packages that are being installed are unintended for general usage. I'd suggest that we should consult a UXD expert for such things. Perhaps @mclarke could help here.

add a warning, or even fail dnf dependency resolution if package outside of a module is resolved against non-api package of the module

We can't actually do this, because there are cases where this is valid. For example, the pki-deps package provides no api because it is just a set of packages that the pki-core package depends on for its functionality. pki-core in turn provides no API directly; it's exposed through either the dogtag or freeipa modules.

This ticket will likely impact libdnf once we figure out what we want to do, so I'm CCing @dmach and @jmracek so they can monitor this.

Login to comment on this ticket.

Metadata