On Mon, 4 Mar 2019 at 05:22, Adam Samalik <asamalik@xxxxxxxxxx> wrote:
>
>
>
> On Mon, Mar 4, 2019 at 11:13 AM 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?
>
>
> That's exactly right, we need to "fix" this situation in Koji. And while we're doing that, we want to maintain consistency between Koji and Mock.
>
I think part of the confusion is that a lot of people just assume koji
mock pulls in packages just like local mock with it pulling data from
/pub/fedora/linux/{releases,updates} versus the generated buildroot
from tagged packages that koji uses. So a lot of the 'oh its so easy,
you can just do this...' doesn't seem to work because what koji mock
repos get is something completely different. [I actually don't know
enough myself to better explain it than .. the koji people said they
were different and it doesn't work the way you think.] Getting a
better diagram of why it doesn't work might help explain to people why
it is taking so long and why various 'oh that would be simple' have
turned into 'ohh that wont work here'.
> The goal is to support standalone packages to depend (both runtime and build time) on default modules — so maintainers can choose wether they can have their packages in a module or not without influencing the rest. However, that work is in progress. We already support the runtime dep part (that's the reason of having /etc/yum.repos.d/fedora-modular.repo on the system) but not the build part because the infra is not ready (that's why we don't have that in mock at the moment).
>
>>
>> > > > 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.
>
>
> That's the point, exactly. But, as I stated above, the work is in progress and we need to maintain consistency. The Java situation is somehow happening earlier than it should.
>
>>
>>
>> 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
>
>
>
> --
>
> Adam Šamalík
> ---------------------------
> Software Engineer
> Red Hat
> _______________________________________________
> 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
--
Stephen J Smoogen.
_______________________________________________
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
