Closed bitsgalore closed 4 years ago
One more thing I just realized: for the 2.0.0 RC we released 1 single Debian package, whereas for the stable releases so far we used to release separate packages for AMD 64 and i386 architectures. Is there any particular reason for this (perhaps something to do with the fact that the latest packages aren't 'frozen' PyInstaller binaries, but I don't know)?
That's exactly it @bitsgalore it's the fact they're not binaries.
@carlwilson thanks for confirming this, in that case I'll also remove the separate download links on the jpylyzer web site for the final release
I just re-ran the docker file, and I now see that -like the Windows binaries- separate packages are built using Python 2.7 and 3.5, respectively. Do we actually need this? From the Debian Python Policy:
Programs should use Python 3, and should not be packaged for Python 2 as well. Python 3 should be used for the packaging if the packaging scripts use Python.
Which suggests we should only provide Debian packages for Python 3, and drop the Python 2 ones.
Also I noticed that docker-package.sh uses a hard-coded value for deb_version (most likely because of the particular formatting needed for the rc). Anyway, set this to pypi_version for now.
As for the hard-coded deb_version
, I added a function that derives this string with the proper formatting from pypi_version
:
https://github.com/openpreserve/jpylyzer/commit/ad852eece00ec137a935e339c2db12d28c1d1532
Dev Effort
5D
Description
Current PyInstaller-based setup seems unnecessary, since jpylyzer' s Python dependencies are fulfilled by current Linux distributions. I would suggest to adopt the packaging used by the python-jpylyzer package.
Provide a suitable repository for apt packages and RPM packages?