On Thu, Nov 14, 2019 at 7:48 PM Stephen Gallagher <sgallagh(a)redhat.com> wrote:
On Thu, Nov 14, 2019 at 12:12 PM Miro HronĨok <mhroncok(a)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?
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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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