Just a follow-up the clear some things up:
* about the -common package (i.e. pysupport namespace issue):
- it's not a must, if one package can act as namespace provider,
there's no need to provide another one, of course,
- being able to list all files provided by packages is something we
really want to have
* dh_python[1] will try to avoid moving files to pyshared if
package supports only one Python version (f.e. the latest one)
* py{,3}compile will support -X/--exclude option
I maintain one module that uses site-packages to keep templates with
.py files inside and although I patched it to move these files outside
site-packages, I know that not every maintainer will want to do that,
so -X will disable byte compilation of files for given directory/file
* about lack of XS-Python-Version and debian/pyversions
- if available, both previous places will be used to get
minimum/maximum required Python version, it will complicate
detection of packages that need binNMU, so I want to drop both of
them at some point,
- dh/cdbs/dh_python will get minimum/maximum required Python versions
from Build-Depends{,-Indep} and/or python-all's Depends.
If one will need to build depend on newer version of
python{,-all,-dev} (due to some Debian specific changes) - tools
will ignore versioned dependencies that include dash sign or use the
lower one if two different dependencies are provided
(f.e. "Build-Depends: python-all-dev (>= 2.5.8), python-all-dev (>= 2.4)"
will be equivalent of "XS-Python-Version: >=2.4")
* how to detect which package needs binNMU?
I think parsing Build-Depends{,-Indep}, Contents file and Depends
header will be enough to detect such packages, i.e. packages that:
- Build-Depends{,-Indep} on python-all{,-dev}
AND there's no <<X.Y build dependency (where X.Y is the one to be introduced)
- Build-Depends on python-dev ("python-dev (>=X.Y) | pythonX.Y-dev" or
"python-dev (<<X.Y)" might help to detect some false positives)
AND provide private extension (/usr/lib/*/*.so)
- Build-Depends{,-Indep} on "python (>=X.Y) | pythonX.Y" and Depend on pythonX.Y
(i.e. "python (>=X.Y) | pythonX.Y" will NOT be in Depends)
[arch:all packages with hardcoded shebang due to default python not
being good enough]
- Build-Depends{,-Indep} on "python" or "python (>=X.Y) | pythonX.Y"
and there's no rtupdate script in binary package
[private modules without hardcoded shebang]
will need binNMU once new Python version will be added to the
supported ones
[1] or "dh_pypython" - I'm still not sure if using the same name is
a good idea as I want to write it in Python and maybe at some point
let someone rewrite it in Perl so that it could be included in
debhelper package.
[Piotr Ożarowski, 2009-08-02]
> $ python3.1 ./3.x/setup.py install --root=debian/python3-foo/
> debian/python3-foo/usr/lib/python3.1/dist-packages/foo/__init__.py
> debian/python3-foo/usr/lib/python3.1/dist-packages/foo/_foo.so
> debian/python3-foo/usr/lib/python3.1/dist-packages/foo/bar.py
will be debian/python3-foo/usr/local/lib... here by default, of course
[...]
> # baz uses Python >= 2.5 and has private extension
> $ python ./setup.py install --root=debian/foo/ --install-lib=/usr/share/privatedir4/ --install-scripts=/usr/share/privatedir4
s,/usr/share/,/usr/lib/,g
> debian/foo/usr/lib/privatedir4/baz/__init__.py
> debian/foo/usr/lib/privatedir4/baz/baz.so
> debian/foo/usr/lib/privatedir4/run.py
--
-=[ Piotr Ożarowski ]=-
-=[ http://www.ozarowski.pl ]=-
Attachment:
signature.asc
Description: Digital signature