Sorry for the long overdue reply here. Answers to your questions are inline. On Wed, Oct 9, 2019 at 6:46 PM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote: ... > What I miss in the description is: > > 1. How does this thing actually work? is there an additional repository composed > from the default streams available in Koji only? An additional repository is composed from the default streams (including the module metadata) and is merged with the standard buildroot using Koji's new "bare" mode. This buildroot will be available for non-Koji purposes (such as mock). > 2. How are conflicts between packages from the default streams and ursine > package be handled? As long as the module metadata is present, an artifact with a given name from an enabled or default module will effectively "hide" the non-modular version. Unless you mean "conflicts" in some other sense, in which case I think RPM-level conflicts should handle it. > 3. What is the local experience if the packager is using mock. What if they are > using rpmbuild directly? For mock, if it's pointed at the Koji-hosted buildroot repository, it will work exactly as Koji does (with no local changes required). If it's pointed at the public mirrors, it will need to have the Modular repos enabled and it will have whatever is in the standard buildroot plus default streams available there. One purpose of this Change is to reconcile those two cases so they are the same. Right now, the Koji buildroot will be slightly different from the one mock would see because FESCo asked us to only allow two modules in the Koji buildroot for testing. Prior to this Change, the Koji buildroot would have only the non-modular content. > 4. How are we handling default streams with dependencies on non-default streams > of other modules? Throughout these discussions, it has been made clear that the best option for now will be to disallow default streams from depending on non-default streams in Fedora. This *can* (but may not) change in the future once we have worked out the explicit-vs-implicit enablement and upgrade questions. But for now, it seems reasonable to put that policy constraint on it. _______________________________________________ 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
