Re: modular repositories in mock configs: please don't

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

When I build in mock, I typically do it to test my changes before
sending a build to koji; I would therefore like the environment to
be nearly identical.  But I'd like to learn about other use cases,
too.

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

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

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.

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

Attachment: signature.asc
Description: PGP signature

_______________________________________________
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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux