On Mon, Mar 4, 2019, 11:12 Pavel Raiskup <prais...@redhat.com> wrote:

> On Monday, March 4, 2019 10:46:45 AM CET Petr Šabata wrote:
> > On Mon, Mar 04, 2019 at 10:22:05AM +0100, Pavel Raiskup wrote:
> > > On Monday, March 4, 2019 10:01:14 AM CET Petr Šabata wrote:
> > > > Replying in general.
> > > >
> > > > While it's never been entirely the same, I'd also like our mock
> configs
> > > > to be as close to koji environment as possible.  In the current
> > > > situation that would mean no modules being available.
> > >
> > > I don't understand your point of view.  If it is safe to enable modular
> > > repositories on user boxes by default (that's what we have now), why we
> > > can not enable them in koji and why we can not enable them in mock?
> >
> > We're currently discussing how to enable them in koji.  It's just not
> > the case at the moment.  Also the module set available and enabled in
> > koji might differ from the repo we ship.
>
> So the thing is to fix koji, not to fix mock - but you suggested to remove
> modular repos from mock config, iirc so why?  So if there's actually a
> reason to do so, shouldn't we removed it from
> /etc/yum.repos.d/fedora-modular.repo as well?
>

I asked for the modular repos to be disabled for mock because they were
causing new build failures - due to failed dependency resolution in modules.

Looking at the other thread (the "please test the 29 -> 30 upgrade with
modules), I'd say that the issue is also present there, and modular repos
shouldn't have been enabled by default for fedora 29 users, either.

Fabio


> > > > Once/if we proceed with one of the
> modules-in-the-non-modular-buildroot
> > > > proposals, I would like them to include the same module set that is
> > > > available in the non-modular buildroot in koji.
> > >
> > > Can you elaborate?  How the 'non-modular buildroot in koji' differs
> from
> > > modules-in-the-non-modular-buildroot?
> >
> > https://pagure.io/fesco/issue/2003
> >
> > The standard buildroot doesn't currently include any modular
> > content.  There are ways to put it in but we haven't decided how
> > to do it yet.
> >
> > Non-modular buildroot is the base buildroot that non-modular
> > packages use to build.  It may or may not include modules.  It
> > currently doesn't but we would like to change that.
> >
> > Once it does, I would like the mock config to include modules that
> > the koji buildroot includes.  Currently it doesn't include any so
> > I'd rather not include any.
>
> Ah, so we consider "modular" content to be a standard, and non-modular to
> be non-standard.  I understood it vice versa before TBH.
>
> > > > If you're building content that depends on modular packages at this
> > > > point, you should be building a module anyway.
> > >
> > > Please elaborate on "why" on this, too.
> >
> > Since the buildroot normally doesn't include modules (see above)
> > and there might be multiple incompatible streams anyway, you
> > should build your content as a module and define proper
> > module-level dependencies on the content you need -- either to
> > build, to run, or both.
>
> You should be able to pick what you build/run/both against, and there
> should be some default (== no stream enabled by default seems to be the
> sanest default to me).
>
> > I don't think this is all that different from normal package
> > builds where you simply declare your RPM-level deps rather than
> > hope that something is magically pulled into the buildroot or
> > already installed on the system.
>
> Well, this comes from my misunderstanding how the modularity is used
> probably...  E.g. there are attempts to move e.g. java stack to modular
> content - only because the MBS allows building against all fedora release
> by one command (== to avoid fedora branching "burden").  Even though this
> use-case is probably a misuse - to explain why I'm asking - I'd still
> expect that the java modular content is somehow available in buildroots
> by default configured in mock.
>
> Pavel
>
> > > > In that case your local MBS manages the build and pulls the relevant
> > > > packages for you.
> > >
> > > Ok, but consider that
> > >
> > >   $ mock -r fedora-rawhide-x86_64 \
> > >
> > >     --config-opts module_enable=postgresql:10
> > >     --rebuild my.srpm
> > >
> > > is much more convenient and economical than approaching the whole MBS
> > > "thingy".
> >
> > This is actually pretty cool.
> >
> > P
>
>
>
> _______________________________________________
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Reply via email to