On 03/01/2022 21:42, Marco Atzeri wrote:
On 03.01.2022 18:37, Jon Turney wrote:
On 31/12/2021 10:00, Marco Atzeri wrote:
Attached patch moves "default" from 3.6 to 3.9
Other point:
As 3.5 was never really deployed, I think we can remove it from the
distribution.
Agreed. I have started collecting a list of packages to do a purge of,
and I'll add those to it.
[...]
Following is a sort of RFC, so let me know your opinion.
Currently we have two type of Python packages
1) Pure python that exists at max as 2.7 3.6 3.7 3.8 3.9 plus 2 and 3
in that case 2/2.7 3/3.6 are EOL;
I stopped last year to update the 2.7 and I am thinking to do the
same for 3.6 now.
I do not see the need to continue to update 3.7, it never become
default as we jumped from 3.6 to 3.8 and it is not more
active upstream:
https://www.python.org/dev/peps/pep-0537/#lifespan
We can update the 3.8 and 3.9 while preparing/testing for 3.10
source package will continue to use the "python-*" form, while
"python3-*" should not be used.
I disagree about the second half of that sentence.
From a package management point of view:
* being able to script 'install python3, python3-foo' and get the foo
for the default python is useful
* having the setup remember that python3-foo was installed (causing
python39-foo to be installed), means when the default python is updated
from python39 to python3nn, setup will also install python3nn-foo, so
local scripts with a python3 shebang which 'import foo' continue to work.
I've posted a cygport patch which adjusts cygport to generate these
python3-foo virtual packages. What do you think about that?
2) python packages derived from other packages, where the
nomenclature is not uniform:
Where we have all variants
libxml2 python27-libxml2
libxml2 python36-libxml2
libxml2 python37-libxml2
libxml2 python38-libxml2
Only one as I moved from supporting 2 to supporting only 3
postgresql postgresql-plpython
To hybrid version
openbabel python2-openbabel (not updated anymore)
openbabel python38-openbabel
I think we should stop to call derived packages "python3-*".
Or we use the full version as python38-openbabel or
no version at all as python-gdal
I think where the package produces a python binding for a specific
python version, the package name should have that version (i.e.
python3x-foo).
In general
We should also stop to pull as dependency "python3"
or "python3-devel" as build dependency.
Use the full version for dependencies.
I don't think those need to appear in the BUILD_REQUIRES at all.
scallywag is capable of inferring from 'inherit python*' that certain
python packages are build requirements.
Plus use "python3_fix_shebang SCRIPT" for setting the proper
interpreter and avoid the issue seen on mercurial and dblatex
https://cygwin.com/pipermail/cygwin/2021-December/250282.html
I used a cruder version but python3_fix_shebang should do the work
