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
?
(Side note: that tracker has gotten badly backlogged, but Petr Sabata
and I are planning to go through it tomorrow to clean it up and
prioritize things. Don't be frightened by its current state!)