Re: new dh_python proposal
On 03.08.2009 19:16, Piotr Ożarowski wrote:
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
packaging the zope tree by choosing existing packages to include the __init__.py
files did work well. Afaik there's no other package in debian not shipping
files, and then creating these.
* 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")
Why move this attribute from an explicit place to an implicit one? Encoding all
stuff in dependencies isn't that obvious. Indeed we do create new attributes
like Homepage, which were included before in the description.
* 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
Is it really worth adding semantics to the build dependency/dependency fields
and instead removing the explicit information about version information?
> Advantages:
> * a lot less opportunities to break a system while installing / upgrading
> Python packages,
> * no more problems with packages that provide the same namespace and use
> different helper tool,
> * Python modules available out of the box (think about daemons),
I appreciate these goals and I'm fine to provide a wrapper for dh_pycentral if
the new dh_python implements these goals.
Matthias
Reply to: