On Fri, 22 May 2020 at 12:02, Miro Hrončok <mhron...@redhat.com> wrote:
> On 22. 05. 20 12:43, Tomasz Kłoczko wrote: > > [mode=serious] > > On making transition from 3.8.x to 3.9.x all what would be necessary to > do would > > be just create compat-python3.8 package -> upgrade python.spec to 3.9 -> > monitor > > number of packages still dependent on compat-python3.8 to focus what > still needs > > to be ported/rebuild. ...snip > > This doesn't work. As long as you rebuild setuptools and other essential > packages with 3.9, the entire 3.8 stack would be useless. You would need > compat > packages for hundreds of packages to make this work. > Is that not *the* target/goal? .. make whole old stack useless/obsolete ASAP? And no you would not need that because as long as you will not remove from repository all python-<module>-<version.foo>-<release.bar>.f22 packages all dependencies will be fulfilled. Remember that each package is not rebuild on entire system but on very limited one with (theoretically) necessary dependencies. With that it is possible to rebuild all packages one by one and move everything in one batch. To make that whole transition easier all what will be necessary to do is clone current repository to something like fedora-transition-python and add keep all rebuild packages in that repo and merge all that packages in one go when all will be finished. No stress or time pressure. such transition can take weeks if not months and decision about merge could be done instantly basing on only one metric which is number of packages still dependent on compat-python3.8. Than if at the and will be still some remains hard quickly to port it should be made decision about create some limited number of packages like compat-python3.8-<module> and/or to put some of those packages on obsoletes list. With single metric decision about actual transition will be no longer in hands of anyone (as single person or comity). It will be strict technical decision based on quite well defined set of conditions hanging on that metric. If we are talking about using that methodology not only for python in some simple enough cases such decision could be done .. automatically! Basing on my already +25y exp on building rpm packages I can even bet that after some cleanups in all python related stuff it should be possible to make python major release upgrade *automatically.* Whoever would want to help on that transition will be asked to add that fedora-transition-python repository to own build systems or own personal system. Initial set of rebuilds made automatically should provide enough set of new dependencies allowing fixing one by one each package which will need manual intervention in form of some patches. Above and what I wrote in my prev email could be general methodology on making any future transition of bigger groups of packages from one major version to another one (not only python specific). All this is just like git branching but on packages with packages repositories as well. It is yet another consequence of what I've sketched. With that it would be possible to remove all python packages bootstrap bconds: [tkloczko@barrel SPECS.fedora]$ grep bootstrap python* | grep bcond python3.spec:%bcond_with bootstrap python-BTrees.spec:%bcond_with bootstrap python-dask.spec:%bcond_without bootstrap python-fsspec.spec:%bcond_without bootstrap python-pbr.spec:%bcond_with bootstrap python-setuptools.spec:%bcond_with bootstrap python-setuptools.spec:# Warning, different bootstrap meaning here, has nothing to do with our bcond python-sphinx_rtd_theme.spec:%bcond_with bootstrap python-stestr.spec:%bcond_without bootstrap python-wheel.spec:%bcond_with bootstrap python-zbase32.spec:%bcond_with bootstrap Of course to that picture needs to be added yet another small bit which is stop (the h*ll) using versioned symlinks in case tools like pytest, sphins and few other to use them *only* in compat-* packages. kloczek
_______________________________________________ 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
