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

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

 



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