On 2020-05-22 13:59, Tomasz Kłoczko wrote:
On Fri, 22 May 2020 at 12:02, Miro Hrončok <mhroncok@xxxxxxxxxx
<mailto:mhroncok@xxxxxxxxxx>> 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.
How is this "fedora-transition-python" different from a side tag?
The problem with "cloning" is that people build new versions in Fedora
all the time, so the "clone" gets out of date (with some additional
problems related to version/release numbers). Unless the "clone" is kept
up to date, merging the repo would mean downgrading some packages.
That is the main reason for the time pressure: the longer the rebuild
takes, the more the repos diverge.
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.
So, what conditions do you propose?
Why would a condition (decided by one person or commitee) be better than
that person (or comittee) deciding on the fly -- based on not just the
number, but the actual packages that still fail to build?
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.*
I'm afraid the clean-ups, and keeping the clean-ups up to date, would be
more work than doing the work manually.
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.
That's very similar to what's been happening in COPR for months now.
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.
Branching is not hard; merging is. Both Git and CVS could branch; Git
won because the *merging* (and thus the whole branch-based workflow) is
easier.
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
Sorry, I don't see how this would be possible.
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.
Yup, it's always better to not use versioned symlinks like pytest-3.8,
and instead use "python3 -m pytest".
Most tools allow this, but, unfortunately, both pytest and sphinx
currently break (in more or less subtle ways) when you do this :(
_______________________________________________
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
