From Gramps
Jump to: navigation, search

How python packages are handled and generated under a .deb based linux distribution?

  • Investigation1: download and uncompress a python gobject, gtk application like MyPaint - SCons build.
    • Repository - url : via one ppa for Ubuntu
    • two packages:
      • one for data (non-python files):
      • one for python modules

Package: mypaint-data Source: mypaint Version: 1.1.0+git20130320-1ppa1~precise1 Architecture: all Maintainer: Python Applications Packaging Team <[email protected]>

Package: mypaint Version: 1.1.0+git20130320-1ppa1~precise1 Architecture: i386 Maintainer: Python Applications Packaging Team <[email protected]>

python support?

pycompile -p mypaint /usr/share/mypaint -V 2.6-
pyclean -p mypaint
  • Investigation2: what is pyshared environment???
A common location to share, across Python versions, arch-independent files which would otherwise 
go to the directory of system public modules is /usr/share/pyshared. 
For python3, a special location is not required, use /usr/lib/python3/dist-packages.

eg, /usr/share/pyshared/lxml-x.x.x.egg-info Repository - url : via Ubuntu

files under:

pycompile -p python-lxml
pyclean -p python-lxml
  • Investigation3: what is wrong with current experimental .deb?





post-install script will copy and compile these modules via:

$ update-python-modules python-gramps.public # as root, copy with verbose -v flag
link /usr/lib/pymodules/python2.7/gramps-4.0.0alpha5.egg-info
overwrite /usr/lib/pymodules/python2.7/gramps-4.0.0alpha5.egg-info
link /usr/lib/pymodules/python2.7/gramps/
overwrite /usr/lib/pymodules/python2.7/gramps/
link /usr/lib/pymodules/python2.7/gramps/cli/
link /usr/lib/pymodules/python2.7/gramps/gen/utils/resource-path
overwrite /usr/lib/pymodules/python2.7/gramps/gen/utils/resource-path
link /usr/lib/pymodules/python2.7/gramps/
overwrite /usr/lib/pymodules/python2.7/gramps/
Generation of /usr/lib/pymodules/python2.7/.path...
Byte-compilation of whole /usr/lib/pymodules/python2.7...

debian stuff[1]

Debian distributions modify upstream Python in a few ways that are important to understand.

  • Of course, where at all possible, we try to minimize deviations from upstream, but here is an enumeration of the changes you might encounter on a Debian system (and derivatives, such as Ubuntu).
  • dist-packages instead of site-packages.

Third party Python software installed from Debian packages goes into dist-packages, not site-packages. This is to reduce conflict between the system Python, and any from-source Python build you might install manually. The standard profile and pstats modules are not included, due to restrictive redistribution clauses in their license that don’t meet the DFSG. cProfile and hotshot are however included.

  • The python-setuptools package installs the Distribute fork instead of the standard setuptools.
  • The python-virtualenv also uses distribute by default, but can enable classic setuptools with an optional switch.
  • Distutils setup scripts install files in /usr/local/ not sys.prefix (which is normally /usr/).

This is because /usr/ is reserved for files installed from Debian packages. Note that /usr/local/lib/pythonX.Y/dist-packages is in sys.path so that modules not installed from Debian packages can still be accessed by the system Python. Tools like debhelper pass the --install-layout=deb option to the setup script while building a Debian package so that its installs files into /usr/ not /usr/local/.

  • Python 2.7 and 3.3 are multiarch aware.


The two traditionally popular Python helpers, python-support and python-central have both been deprecated in favor of dh_python2.