On Thu, Nov 14, 2019 at 12:59 PM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
On Thu, Nov 14, 2019 at 06:43:42PM +0100, Miro Hrončok wrote:
> On 14. 11. 19 18:36, Zbigniew Jędrzejewski-Szmek wrote:
> >On Thu, Nov 14, 2019 at 06:08:52PM +0100, Miro Hrončok wrote:
> >>On 09. 10. 19 22:46, Ben Cotton wrote:
> >>>https://fedoraproject.org/wiki/Changes/Modules_In_Non-Modular_Buildroot
> >>>
> >>>Enable module default streams in the buildroot repository for modular
> >>>and non-modular RPMs.
> >>>
> >>>== Summary ==
> >>>This Change (colloquially referred to as "Ursa Prime") enables
the
> >>>Koji build-system to include the RPM artifacts provided by module
> >>>default streams in the buildroot when building non-modular (or
> >>>"traditional") RPMs.
> >>
> >>I have one more technical concern.
> >>
> >>Suppose a packager decides to package the "mycoolapp" software as
a
> >>non-modular package. "mycoolapp" is written in Python, it builds
> >>again non-modular Python, currently 3.8, it requires "python(abi) =
> >>3.8" on runtime.
> >
> >Hmm, and what about an even simpler case:
> >"myswankyapp" is also written in Python, and is packaged as a module.
> >Python is rebuilt in a side tag, then the module blocks the upgrade.
> >What is supposed to happen in that case?
>
> The module is rebuilt after the side tag is merged. Al least that is
> what I think happened with avocado when we upgraded to Python 3.8.
Automatically? And if the build fails?
It's not automatic. Release Engineering has to kick it by hand by
making a weird empty commit and triggering a build.
--
真実はいつも一つ!/ Always, there's only one truth!