#8 Flip the default Python to Python 3
Merged 5 years ago by praiskup. Opened 5 years ago by praiskup.
rpms/ praiskup/gdal python3-default  into  master

file modified
+54 -18
@@ -1,5 +1,4 @@ 

  #TODO: g2clib and grib (said to be modified)

- #TODO: Python 3 modules should be possible since 1.7

  #TODO: Create script to make clean tarball

  #TODO: msg needs to have PublicDecompWT.zip from EUMETSAT, which is not free;

  #      Building without msg therefore
@@ -51,6 +50,9 @@ 

  %global spatialite "--with-spatialite"

  %endif

  

+ %bcond_without python2

+ %bcond_without python3

+ 

  # No ppc64 build for spatialite in EL6

  # https://bugzilla.redhat.com/show_bug.cgi?id=663938

  %if 0%{?rhel} == 6
@@ -62,7 +64,7 @@ 

  

  Name:		gdal

  Version:	2.3.2

- Release:	1%{?dist}%{?bootstrap:.%{bootstrap}.bootstrap}

+ Release:	2%{?dist}%{?bootstrap:.%{bootstrap}.bootstrap}

  Summary:	GIS file format library

  Group:		System Environment/Libraries

  License:	MIT
@@ -146,8 +148,6 @@ 

  %if 0%{?with_mysql}

  BuildRequires:	mariadb-connector-c-devel

  %endif

- BuildRequires:	numpy

- BuildRequires:	python3-numpy

  BuildRequires:	pcre-devel

  BuildRequires:	ogdi-devel

  BuildRequires:	perl-devel
@@ -160,8 +160,14 @@ 

  %endif

  BuildRequires:	libpq-devel

  BuildRequires:	proj-devel

+ %if %{with python2}

  BuildRequires:	python2-devel

+ BuildRequires:	python2-numpy

+ %endif

+ %if %{with python3}

  BuildRequires:	python3-devel

+ BuildRequires:	python3-numpy

+ %endif

  BuildRequires:	sqlite-devel

  BuildRequires:	swig

  %if %{build_refman}
@@ -276,7 +282,7 @@ 

  %description perl

  The GDAL Perl modules provide support to handle multiple GIS file formats.

  

- 

+ %if %{with python2}

  %package -n python2-gdal

  %{?python_provide:%python_provide python2-gdal}

  # Remove before F30
@@ -291,8 +297,10 @@ 

  %description -n python2-gdal

  The GDAL Python modules provide support to handle multiple GIS file formats.

  The package also includes a couple of useful utilities in Python.

+ %endif

  

  

+ %if %{with python3}

  %package -n python3-gdal

  %{?python_provide:%python_provide python3-gdal}

  Summary:	Python modules for the GDAL file format library
@@ -304,6 +312,18 @@ 

  

  %description -n python3-gdal

  The GDAL Python 3 modules provide support to handle multiple GIS file formats.

+ %endif

+ 

+ 

+ %if %{with python2} || %{with python3}

+ %package python-tools

+ Summary:	Python tools for the GDAL file format library

+ Requires:	%{?with_python3:python3-gdal}%{?!with_python3:python2-gdal}

+ 

+ %description python-tools

+ The GDAL Python package provides number of tools for programming and

+ manipulating GDAL file format library

+ %endif

  

  

  %package doc
@@ -381,6 +401,7 @@ 

  # http://trac.osgeo.org/gdal/ticket/3602

  sed -i 's|libproj.so|libproj.so.%{proj_somaj}|g' ogr/ogrct.cpp

  

+ %if %{with python3} || %{with python2}

  # Fix Python samples to depend on correct interpreter

  mkdir -p swig/python3/samples

  pushd swig/python/samples
@@ -390,6 +411,7 @@ 

    sed -i 's|^#!.\+python$|#!/usr/bin/python2|' $f

  done

  popd

+ %endif

  

  # Adjust check for LibDAP version

  # http://trac.osgeo.org/gdal/ticket/4545
@@ -504,8 +526,8 @@ 

  

  # Make Python modules

  pushd swig/python

-   %py3_build

-   %py2_build

+   %{?with_python2:%py2_build}

+   %{?with_python3:%py3_build}

  popd

  

  # Make Python modules
@@ -552,8 +574,8 @@ 

  rm -rf %{buildroot}

  

  pushd swig/python

-   %py3_install

-   %py2_install

+   %{?with_python2:%py2_install}

+   %{?with_python3:%py3_install}

  popd

  

  pushd swig/perl
@@ -576,6 +598,10 @@ 

  find %{buildroot}%{perl_vendorarch} -name "*.dox" -exec rm -rf '{}' \;

  rm %{buildroot}%{perl_archlib}/perllocal.pod

  

+ %if %{without python} && %{without python3}

+ rm %buildroot%_mandir/man1/{pct2rgb,rgb2pct}.1

+ %endif

+ 

  # Correct permissions

  #TODO and potential ticket: Why are the permissions not correct?

  find %{buildroot}%{perl_vendorarch} -name "*.so" -exec chmod 755 '{}' \;
@@ -826,25 +852,19 @@ 

  %{perl_vendorarch}/*

  %{_mandir}/man3/*.3pm*

  

+ %if %{with python2}

  %files -n python2-gdal

  %doc swig/python/README.txt

  %doc swig/python/samples

- #TODO: Bug with .py files in EPEL 5 bindir, see http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies

- %{_bindir}/*.py

- %{_mandir}/man1/pct2rgb.1*

- %{_mandir}/man1/rgb2pct.1*

- %{_mandir}/man1/gdal2tiles.1*

- %{_mandir}/man1/gdal_fillnodata.1*

- %{_mandir}/man1/gdal_merge.1*

- %{_mandir}/man1/gdal_retile.1*

- %{_mandir}/man1/gdal_sieve.1*

  %{python2_sitearch}/osgeo

  %{python2_sitearch}/GDAL-%{version}-py*.egg-info

  %{python2_sitearch}/osr.py*

  %{python2_sitearch}/ogr.py*

  %{python2_sitearch}/gdal*.py*

  %{python2_sitearch}/gnm.py*

+ %endif

  

+ %if %{with python3}

  %files -n python3-gdal

  %doc swig/python/README.txt

  %doc swig/python3/samples
@@ -858,6 +878,19 @@ 

  %{python3_sitearch}/__pycache__/gdal*.*.py*

  %{python3_sitearch}/gnm.py*

  %{python3_sitearch}/__pycache__/gnm.*.py*

+ %endif

+ 

+ %if %{with python2} || %{with python3}

+ %files python-tools

+ %_bindir/*.py

+ %{_mandir}/man1/pct2rgb.1*

+ %{_mandir}/man1/rgb2pct.1*

+ %{_mandir}/man1/gdal2tiles.1*

+ %{_mandir}/man1/gdal_fillnodata.1*

+ %{_mandir}/man1/gdal_merge.1*

+ %{_mandir}/man1/gdal_retile.1*

+ %{_mandir}/man1/gdal_sieve.1*

+ %endif

  

  %files doc

  %doc gdal_frmts ogrsf_frmts refman
@@ -871,6 +904,9 @@ 

  #Or as before, using ldconfig

  

  %changelog

+ * Thu Oct 04 2018 Pavel Raiskup <praiskup@redhat.com> - 2.3.2-2

+ - Python 3 is the default Python now

+ 

  * Mon Oct  1 2018 Volker Fröhlich <volker27@gmx.at> - 2.3.2-1

  - New upstream release

  

Resolves: rhbz#1437185

@volter, @devrim quick review would be appreciated.

  • python scripts moved to 'gdal-python', which depends on 'python3-gdal' (or python2-gdal)
  • added --without={python2,python3} options.
  • Python 3 is the default now

this one should go as well

Bikeshedding about the package name: what about gdal-python-tools?

Thanks for the review!

I have no strong opinion about gdal-python-tools so I'd probably use what you propose (if there are no objections).

Regarding numpy vs python2-numpy, dunno. I didn't want to complicate porting the spec file to epel.

Both the summary and the description have some grammar problem.

I'm a bit lost: Will we have 3 sub-packages now? Two providing the Python libs and one that has the utility scripts? If so, I find it confusing.

Ok, python2-numpy seems to be safe, thanks.

Both the summary and the description have some grammar problem. I'm a bit lost: Will we have 3 sub-packages now? Two providing the Python libs and one that has the utility scripts? If so, I find it confusing.

I doesn't seem to be very confusing to me (those who need python module install python module, those who need scripts install gdal-python-tools), but I think it is matter of taste. So what do you prefer?

rebased onto bc84437

5 years ago

If the name is gdal-python-tools, I don't find it confusing anymore. As a side-note: Debian has the scripts in the respective Python sub-packages, not inside an extra-package.

Debian has the scripts in the respective Python sub-packages, not inside an extra-package.

I've checked debian packages, and I found it a bit unfortunate that they provide the scripts only in python(2)-gdal, not in python3-gdal (which is supposed to be the default in Fedora nowadays).

So if we did something similar, the scripts should be in python3-gdal at least, or we should provide the scripts in both python{2,3}-gdal, but doing
s/epsg_tr.py/epsg_tr3.py to have both versions is a bit artificial.

Having dedicated package where users don't have to care about python versions sounds much more convenient.

I also had an idea to put those script files into gdal.rpm directly, and require corresponding python module. What do you think?

I also had an idea to put those script files into gdal.rpm directly, and require corresponding python module. What do you think?

That depends on how many new deps this will bring. If it's just python3, I think we are fine (it's installed most of the time anyway). If its a bunch of modules, I'm not sure. But this is also a solution.

You could also keep it in gdal-python-tools and recommend the tools from gdal.

Do I get it right this is good to go then?

(rebase to resolve conflicts)

rebased onto 866b1a5

5 years ago

Do I get it right this is good to go then?

Not sure who was this question for, but it's definitively good to go for me.

Because there are no downvotes, merging. Thanks for having a look!

Pull-Request has been merged by praiskup

5 years ago