On Wed, 9 Oct 2019 at 19:56, Miro Hrončok <mhroncok@xxxxxxxxxx> wrote: > > On 10. 10. 19 1:44, Stephen John Smoogen wrote: > > On Wed, 9 Oct 2019 at 18:46, 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? > >> > >> 2. How are conflicts between packages from the default streams and ursine > >> package be handled? > >> > >> 3. What is the local experience if the packager is using mock. What if they are > >> using rpmbuild directly? > >> > > > > So from doing a lot of builds with mock, then the packager should be > > ok because mock pulls in modules and you can define in mock which > > module streams you want if you needed something differently. For > > rpmbuild it is a bit harder because you may have used one module on > > your local system and built with another.. However in someways this is > > similar to rpm where I might have installed an F31 package on my F30 > > system to test something and then found out my local rpmbuild didn't > > work. > > > > In many ways I found working with mock easier than working with any of > > the other system tools when dealing with modules. The file is very > > well commented and it was clear what I needed to do to make it work. > > So I can't answer anything else.. but I think the local experience for > > mock users will be smoother than elsewhere. > > What I really care about here is that the mock experience more or less equals > the Koji experience. I.e. I don't want the packagers to (need to) enable modules > in mock when in fact in Koji they are not enabled, but some other magic is > happening. > > Having a description about what this change actually does to enable modules in > the buildroot will hopefully steer this discussion more to the specifics of how > to enable the same thing in mock (by default). So for all my builds.. it works by default in mock already. [I am not going to say that it works for everyone.. but when I rebuilt a couple thousand packages earlier with mockchain.. mock did the right thing without me futzing.] It is in koji that it fails because koji has no idea about modules and does not pass any of the extra data mock can use to make decisions for itself. [I believe Koji doesn't want mock to make decisions because then the build is not record-ably reproducible.] This is more about making the decisions that mock would do for itself be something koji would be able to record and force. [AKA where mock would use dnf to pull in the default module X, koji instead determines all the packages to put into its own repo that it points mock on the builder to. This is meant to make sure the build is auditable and repeatable.] -- Stephen J Smoogen. _______________________________________________ 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
