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? > > > 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
