On Thu, Nov 14, 2019 at 12:12 PM Miro Hrončok <mhroncok@xxxxxxxxxx> 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. > > The packager decides to use avocado in %check. Avocado comes from a module, it > requires "python(abi) = 3.8" as well, because the modular package was built with > Python 3.8. Avocado is in the bulidroot, so everything works. > > The Python maintainers (that includes me) decide to update to Python 3.9 in > Fedora 33. They request a side tag to do that. They update the python3 to 3.9 > and they mass rebuild all non-modular Python packages in it. "mycoolapp" cannot > resolve build dependencies because avocado requires "python(abi) = 3.8". > > The Python maintainers need to detect this and figure out what happened. > Then, the Python maintainers need to either: > > 1. Exclude "mycoolapp" from the rebuild. That is possible until dozens of > other packages require "mycoolapp". > > 2. Ask the avocado maintainers to rebuild their module in the side tag and ask > releng to add the side-tag-built module into the side-tag buildroot (if it is > even possible). > > 3. Modify the spec of "mycoolapp" to temporarily disable %check and loose the > avocado dependency. > > Or is there some other way? > Does Python actually break ABI on minor releases? So a full rebuild is required for that case? What we would probably need to do is tag the python39 build into the modular buildroot for the appropriate platform and then rebuild avocado while that was in the buildroot. Another option would be to create a `python3` module stream for each minor release and make one of them the default stream for the side-tag so the non-modular versions could be built against that. Then the avocado module would set its dependencies to be: ``` buildrequires: platform: [ ] python3: [ ] ``` (Read: build for all streams of python for all available platforms). Then whenever the default stream of python3 changes over in Rawhide, avocado would follow because it was already built for the next version. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
