On 14. 11. 19 20:58, Stephen Gallagher wrote:
On Thu, Nov 14, 2019 at 1:33 PM Miro Hrončok
<mhroncok(a)redhat.com> wrote:
>
> On 14. 11. 19 19:11, Zbigniew Jędrzejewski-Szmek wrote:
>> On Thu, Nov 14, 2019 at 01:00:52PM -0500, Neal Gompa wrote:
>>> 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.
>>
>> And if the build fails?
>>
>> In case this isn't obvious: right now python-sig will pummel all the
>> modules until they stop FTBFSing. If modules don't get the same
>> treatment, we have a problem.
>
> Currently, modules don't get the same treatment. The reason basically is:
>
> I don't know how to repoquery all modules to see what modular packages still
> require Python 3.7. I was trying to get this information but at a certain point,
> I've stopped trying.
>
That's a reasonable concern and a problem we do need to solve. Would
you mind adding it to
https://pagure.io/modularity/issues ?