On 14. 11. 19 19:39, Stephen Gallagher wrote:
On Thu, Nov 14, 2019 at 12:12 PM Miro Hrončok <mhron...@redhat.com> 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.
See one failed attempt at https://fedoraproject.org/wiki/Changes/System_Python
See a very nasty hack in RHEL 8.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
