On 10/15/19 9:26 PM, Stephen Gallagher wrote:
Module stream metadata would gain two new optional attributes, "upgrades:" and "obsoletes:". If the "upgrades: <older_stream>" field exists in the metadata, libdnf should switch to this stream if the following conditions are met: 1) Changing the stream would not introduce conflicts. 2) The stream is marked as `default_enabled` or `dep_enabled`. The "obsoletes: <older_stream>" field would be stronger. Its use should require a special exemption (with a strong justification) and it would cause libdnf to switch from that stream to this one *unconditionally* (failing the transaction if that transition would cause conflicts). This would essentially be an "emergency escape" if we need it.
Modularity has multiple use cases: your proposal addresses the OS usage where modularity manages installed distribution's dependency versioning issues. What would happen if someone installed certain module stream to manage their own version requirements? Presumably, they might want to _never_ change the stream. How is that handled in your scheme? I think the "upgrades:" case would be fine, because explicit installation would not have the "default_enabled" attribute. However, if a new module declared the "obsoletes:", it would replace them no matter what. Would there be a way to prevent that, or are you arguing that such override should not be allowed?
_______________________________________________ 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
