On Thu, Nov 14, 2019 at 2:10 PM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote: > > On 14. 11. 19 19:39, Stephen Gallagher 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? > > Yes, the full rebuild is needed for various reasons. We've talked about this on > IRC, but to make this more transparent to others, I will repeat it here. The > main reasons include that "3.8" is in the paths (such as /usr/lib/python3.8) and > that the bytecode is changed. There are other reasons that may or may not be > relevant to avocade. > > > 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. > > This would affect all modules that need to be rebuilt before the python39 > side-tag is merged, right? > > If I understand that right, it would also make the avocado module > non-installable for regular rawhide buidlroot before the python39 side tag is > merged. > > One of the purposes that we do this in the side tag is to avoid disrupting > rawhide while we are mid-upgrade. > > > 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. > > Modular stream of what module? > > > 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. > > Default stream of python3? python3 is not a module. And even if I wanted it to > be (I don't), it would be a very hard thing to do. > So, what I meant here (as I said in another mail) was actually to create a python3 module with streams for each release version whose purpose is *not* to carry the actual python content. That should stay with the non-modular RPMs. It would instead carry just a (new) python-binaries package that would behave halfway between `alternatives` and a metapackage, in that it would depend on the appropriate non-modular packages and drop symlinks for the correct binary versions into place. Then we could use those module streams as source for doing stream expansion for modules that depend on Python. Then it becomes easy to rebuild things like Avocado, since it will see the new 3.9 stream and add that to the matrix. Am I explaining that well? _______________________________________________ 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
