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 noX.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
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: from python egg to debian package : a good example ?
[Ben Finney, 2009-08-20] Piotr Ożarowski pi...@debian.org writes: [Jérémy Lal, 2009-08-18] i'm willing to package a python module (orbited, see http://orbited.org). I suppose there's a clever way when the said module is a python egg. There's tar.gz on PyPi, no need to use Egg. This is true for the ‘orbited’ distribution, but only because the distribution owner has uploaded a tarball. Can you point me to a project that is providing eggs only? anyway, here's what I'd do in such case: * check if upstream is using VCS (tarball can be created from files in the repo), or * ask upstream to point me to the sources, or * unzip .egg, add setup.py, create tarball, send setup.py upstream -- -=[ Piotr Ożarowski ]=- -=[ http://www.ozarowski.pl ]=- -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: from python egg to debian package : a good example ?
On 20/08/2009 11:24, Piotr Ożarowski wrote: [Ben Finney, 2009-08-20] Piotr Ożarowskipi...@debian.org writes: [Jérémy Lal, 2009-08-18] i'm willing to package a python module (orbited, see http://orbited.org). I suppose there's a clever way when the said module is a python egg. There's tar.gz on PyPi, no need to use Egg. This is true for the ‘orbited’ distribution, but only because the distribution owner has uploaded a tarball. Can you point me to a project that is providing eggs only? anyway, here's what I'd do in such case: * check if upstream is using VCS (tarball can be created from files in the repo), or * ask upstream to point me to the sources, or * unzip .egg, add setup.py, create tarball, send setup.py upstream I was confused and made an omelet with the egg :) Indeed the tarball contains setup.py, and dh_pycentral did the job. Regards, Jérémy. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: from python egg to debian package : a good example ?
Piotr Ożarowski pi...@debian.org writes: Can you point me to a project that is providing eggs only? For a while my own did, until I realised that tarballs were a better option. I've also seen distribution entries that have no files at all, just meta-data. My point is that it needs to be realised that *if* a distribution isn't providing tarballs, that's not because PyPI has failed; it makes no guarantee that *any* distribution files are downloadable. Therefore one should not rely on them being available. -- \ “The lift is being fixed for the day. During that time we | `\regret that you will be unbearable.” —hotel, Bucharest | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: from python egg to debian package : a good example ?
Jérémy Lal je...@edagames.com writes: Indeed the tarball contains setup.py, and dh_pycentral did the job. Note again, though, that new packaging work shouldn't rely on ‘python-central’; it has many problems that are tedious to recover from. Instead, use ‘python-support’. -- \ “About four years ago, I was — no, it was yesterday.” —Steven | `\Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: from python egg to debian package : a good example ?
On 20/08/2009 12:57, Ben Finney wrote: Jérémy Lalje...@edagames.com writes: Indeed the tarball contains setup.py, and dh_pycentral did the job. Note again, though, that new packaging work shouldn't rely on ‘python-central’; it has many problems that are tedious to recover from. Instead, use ‘python-support’. Thanks, i just discovered my questions were already answered at http://wiki.debian.org/DebianPythonFAQ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: new dh_python proposal
[Matthias Klose, 2009-08-20] On 03.08.2009 19:16, Piotr Ożarowski wrote: * 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, [...] 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. [...] Is it really worth adding semantics to the build dependency/dependency fields and instead removing the explicit information about version information? * to ease detecting packages that need binNMU? * to make it simpler for package maintainers (my module needs Python =2.4 - lets build depend on it instead of where the heck is XS-P-V / debian/pyversion's syntax described?) * to make it easier for dh/cdbs maintainers? Anyway, I don't care about it that much, it will not make any difference if we decide to support all 3 approaches or only existing two (both previous ones has to be supported at the beginning anyway). -- -=[ Piotr Ożarowski ]=- -=[ http://www.ozarowski.pl ]=- signature.asc Description: Digital signature
Re: apps-team, modules-team: pet.cgi gives bad SVN links
[Piotr Ożarowski, 2009-08-19] [Jonathan Wiltshire, 2009-08-13] It doesn't seem to affect the Perl team's PET, so I guess it's local configuration. Is it something I can fix? bug forwarded upstream ;-) thanks (PET/bin/templates/by_category, line 281 doesn't work with layout=1) fixed thanks to guys from #pet-devel (in pet.conf, we were using wsvn_url which is no longer supported) -- -=[ Piotr Ożarowski ]=- -=[ http://www.ozarowski.pl ]=- signature.asc Description: Digital signature
