On 10. 10. 19 16:15, Stephen John Smoogen wrote:
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.]
AFAIK mock has currently modular repos disabled by default for Fedora configs.
So it might work for EPEL8, or it might work if you enable them, or it might
work because no modules were used at all.
It does not "work by default" for Fedora modules.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
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
