On Mon, Mar 4, 2019, 11:12 Pavel Raiskup <praiskup@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
