#147 Warn the user somehow when dependencies are resolved against non-api package
Closed: Invalid 6 months ago by dmach. Opened a year ago by bookwar.

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.

I suggest we should close it. Be honest anything that is shipped in distribution can be used as a source of API. Additional warning will make people only confused or unhappy. Playing the game whit what is supported and what not is dangerous one.

The change must be not on DNF/libdnf level but in responsibility of maintainers. If you ship/build something then you have to support and maintain it.

Agreed. The current depsolver doesn't distinguish between api/non-api packages and doing so would increase depsolving complexity which is already too high and most likely cause problems with already released content.
Closing.

Metadata Update from @dmach:
- Issue close_status updated to: Invalid
- Issue status updated to: Closed (was: Open)

6 months ago

I agree that this should not be presented to the user; they would not be the right people to do something about this.

However, we should probably have tests for this in the OSCI environment to report such mistakes to the maintainer.

Login to comment on this ticket.

Metadata