On Thu, Nov 14, 2019 at 7:48 PM Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote: > > 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. That would mean, each release - bunch of additional manual work. > 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. This implies that Python maintainers want to deal with Modularity which I believe is not the case. > _______________________________________________ > 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 _______________________________________________ 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
