New python policy
Hello everybody,
there has (again) been some grumblings about the python transition (hi
Thomas!). The python Bof at the debconf has been successfull at deciding a
new python policy. However this policy is not implemented yet. That's what
causing this delay...
The new policy is more or less the following (people may correct me if I'm
wrong):
The major changes are for packages providing public modules:
* they should support all current python versions (the set of supported
python versions is defined by the python-all and python-all-dev packages)
* the same packages should indicate via an XC-Python-Version field in the
debian/control file (source paragraph) the python versions that they
support. This field can be either a list of supported versions ("2.3,
2.4") or an interval (">= 2.4" or ">=2.1, <<2.4") or "all" (if no
restrictions are known).
* the dependencies (hopefully created automatically by dh_python) will
indicate the right interval automatically:
right now for example it would be "python (>=2.3), python (<< 2.5)"
for a package saying "XC-Python-Version: all"
* the packages should provide all "python2.X-foo"
that they really provide (i.e. it must of course correspond to the
content of the package, which in turn should correspond to what
XC-Python-Version says). This Provides field can also be generated
by dh_python. (This is particularly relevant for binary modules of
course but it can make sense for non-binary modules as well, for example
if they don't support an old version anymore, stopping to provide
python2.3-foo would for example forbid upgrading a /usr/bin/python2.3
application relying on it)
For applications:
* if they use /usr/bin/python, they should simply depend on python-foo
modules that they use.
* if they use /usr/bin/python2.X, they should depend on python2.X-foo
modules that they use.
For private modules (not sure here):
* no change except that they can also use XC-Python-Version to get
a good python dependency automatically
As you can see, the bulk of the work is:
- modifying the rules file to build all versions for binary modules
- implementing the dh_python changes
Note: The policy doesn't require pycentral or python-support. But both of
these tools help to achieve the multiple-version support with a single
copy of the .py files.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New python policy
On Fri, 2006-06-02 at 12:52 +0200, Raphael Hertzog wrote: > * the dependencies (hopefully created automatically by dh_python) will > indicate the right interval automatically: > right now for example it would be "python (>=2.3), python (<< 2.5)" > for a package saying "XC-Python-Version: all" What's the point of such a tight upper dependency? The whole idea was to reduce the work for transitions, this still requires a rebuild when we upgrade to Python 2.5 (or in fact, whenever the supported versions of Python change). Such information is necessary for extensions, but irrelevant for programs or other modules. > * the packages should provide all "python2.X-foo" > that they really provide (i.e. it must of course correspond to the > content of the package, which in turn should correspond to what > XC-Python-Version says). This Provides field can also be generated > by dh_python. (This is particularly relevant for binary modules of > course but it can make sense for non-binary modules as well, for example > if they don't support an old version anymore, stopping to provide > python2.3-foo would for example forbid upgrading a /usr/bin/python2.3 > application relying on it) > > For applications: > * if they use /usr/bin/python, they should simply depend on python-foo > modules that they use. > * if they use /usr/bin/python2.X, they should depend on python2.X-foo > modules that they use. IMO use of python2.x-foo should be discouraged. Maintainers of applications that need specific Python versions should ask maintainers of the modules they need, and only the ones they need, to provide the version-specific virtual package. > For private modules (not sure here): > * no change except that they can also use XC-Python-Version to get > a good python dependency automatically See my first comment. This misses the point, if an application has to be rebuilt whenever the Python version changes. Then all we get is a precarious tower of tools to do exactly what we did before. Given that we still have a ton of (virtual) python2.x-foo packages under this policy, and any Python package would still need to be rebuilt during a transition, I don't see how this policy does anything useful. -- Joe Wreschnig <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: New python policy
Joe Wreschnig writes: > On Fri, 2006-06-02 at 12:52 +0200, Raphael Hertzog wrote: > > * the dependencies (hopefully created automatically by dh_python) will > > indicate the right interval automatically: > > right now for example it would be "python (>=2.3), python (<< 2.5)" > > for a package saying "XC-Python-Version: all" > > What's the point of such a tight upper dependency? The whole idea was to > reduce the work for transitions, this still requires a rebuild when we > upgrade to Python 2.5 (or in fact, whenever the supported versions of > Python change). > > Such information is necessary for extensions, but irrelevant for > programs or other modules. No, see my posting from February. If a module depends on an extension, it has to have this strict dependency. > > * the packages should provide all "python2.X-foo" > > that they really provide (i.e. it must of course correspond to the > > content of the package, which in turn should correspond to what > > XC-Python-Version says). This Provides field can also be generated > > by dh_python. (This is particularly relevant for binary modules of > > course but it can make sense for non-binary modules as well, for example > > if they don't support an old version anymore, stopping to provide > > python2.3-foo would for example forbid upgrading a /usr/bin/python2.3 > > application relying on it) > > > > For applications: > > * if they use /usr/bin/python, they should simply depend on python-foo > > modules that they use. > > * if they use /usr/bin/python2.X, they should depend on python2.X-foo > > modules that they use. > > IMO use of python2.x-foo should be discouraged. Maintainers of > applications that need specific Python versions should ask maintainers > of the modules they need, and only the ones they need, to provide the > version-specific virtual package. correct, but for those applications we try to include support for all supported python versions in python-foo. > > For private modules (not sure here): > > * no change except that they can also use XC-Python-Version to get > > a good python dependency automatically > > See my first comment. This misses the point, if an application has to be > rebuilt whenever the Python version changes. Then all we get is a > precarious tower of tools to do exactly what we did before. only if the application uses a non-default python version. > Given that we still have a ton of (virtual) python2.x-foo packages under > this policy, and any Python package would still need to be rebuilt > during a transition, I don't see how this policy does anything useful. see my slides from Debconf. - we are able to make a transition with one upload (python-defaults) - no extension modules need to be uploaded for a transition (potentially depending on new shlibs). - all rebuilds/uploads can be handled by bin-NMU's. that sounds pretty useful. Matthias http://people.debian.org/~doko/pycentral/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New python policy
On Fri, Jun 02, 2006 at 11:50:53AM -0500, Joe Wreschnig wrote: > On Fri, 2006-06-02 at 12:52 +0200, Raphael Hertzog wrote: > > * the dependencies (hopefully created automatically by dh_python) will > > indicate the right interval automatically: > > right now for example it would be "python (>=2.3), python (<< 2.5)" > > for a package saying "XC-Python-Version: all" > What's the point of such a tight upper dependency? The whole idea was to > reduce the work for transitions, this still requires a rebuild when we > upgrade to Python 2.5 (or in fact, whenever the supported versions of > Python change). > Such information is necessary for extensions, but irrelevant for > programs or other modules. Indeed, the intent was that this strict upper bound would apply to extensions, not to modules. Not sure if that intent got lost somewhere along the way. > IMO use of python2.x-foo should be discouraged. Maintainers of > applications that need specific Python versions should ask maintainers > of the modules they need, and only the ones they need, to provide the > version-specific virtual package. Yes, this was also discussed in the BoF, with the same conclusion: because providing python2.x-foo can only be done safely if the package depends on the python2.x versions of all other modules it requires, making transitions more brittle as a result, these virtual packages should really only be provided in response to specific demand for them. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: on packaging TurboGears 0.8.9
On 5/18/06, Gustavo Noronha Silva <[EMAIL PROTECTED]> wrote: Hey! Em Sáb, 2006-05-13 às 21:42 -0300, Gustavo Noronha Silva escreveu: > Comments? Bug reports to my email address, please. May I go on and > upload the packages to unstable? I'll upload TurboGears 0.9 to > experimental, if it is ok, 'till it is released as stable. The modules > will go straight to unstable. I am planning to upload the packages this weekend. If noone is against, I'll go ahead and upload all python modules which I had to package for the 0.8 and 0.9 versions to unstable, and TG 0.9 and closely related modules to experimetal. I'll take a look at what still needs changing in current packages and file bugs if they are still in need of updating. Hi Kov, I've installed python-turbogears 0.9a6-1 from your repository[0] and i see the following error message: $ tg-admin quickstart Traceback (most recent call last): File "/usr/bin/tg-admin", line 5, in ? from pkg_resources import load_entry_point File "/usr/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/pkg_resources.py", line 2195, in ? for dist in working_set.resolve( File "/usr/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/pkg_resources.py", line 483, in resolve raise DistributionNotFound(req) # XXX put more info here pkg_resources.DistributionNotFound: TurboGears==0.9a6 [0] = http://people.debian.org/~kov/tg0.9/ Something related with 'eggs' ? regards, -- stratus
Re: New python policy
On Fri, 2006-06-02 at 14:43 -0700, Steve Langasek wrote: > On Fri, Jun 02, 2006 at 11:50:53AM -0500, Joe Wreschnig wrote: > > On Fri, 2006-06-02 at 12:52 +0200, Raphael Hertzog wrote: > > > * the dependencies (hopefully created automatically by dh_python) will > > > indicate the right interval automatically: > > > right now for example it would be "python (>=2.3), python (<< 2.5)" > > > for a package saying "XC-Python-Version: all" > > > What's the point of such a tight upper dependency? The whole idea was to > > reduce the work for transitions, this still requires a rebuild when we > > upgrade to Python 2.5 (or in fact, whenever the supported versions of > > Python change). > > > Such information is necessary for extensions, but irrelevant for > > programs or other modules. > > Indeed, the intent was that this strict upper bound would apply to > extensions, not to modules. Not sure if that intent got lost somewhere > along the way. > > > IMO use of python2.x-foo should be discouraged. Maintainers of > > applications that need specific Python versions should ask maintainers > > of the modules they need, and only the ones they need, to provide the > > version-specific virtual package. > > Yes, this was also discussed in the BoF, with the same conclusion: because > providing python2.x-foo can only be done safely if the package depends on > the python2.x versions of all other modules it requires, making transitions > more brittle as a result, these virtual packages should really only be > provided in response to specific demand for them. For those of us who were not at the BoF and only getting sketchy information about it (e.g. Raphael's information is wrong, or at least horribly incomplete, I guess, and presentation slides are not a good summary of technical policy), when are we going to have a real proposal to comment on, or at least follow? What happened to "Python 2.4 first, new infrastructure later"? -- Joe Wreschnig <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: New python policy
Steve Langasek writes: > On Fri, Jun 02, 2006 at 11:50:53AM -0500, Joe Wreschnig wrote: > > On Fri, 2006-06-02 at 12:52 +0200, Raphael Hertzog wrote: > > > * the dependencies (hopefully created automatically by dh_python) will > > > indicate the right interval automatically: > > > right now for example it would be "python (>=2.3), python (<< 2.5)" > > > for a package saying "XC-Python-Version: all" > > > What's the point of such a tight upper dependency? The whole idea was to > > reduce the work for transitions, this still requires a rebuild when we > > upgrade to Python 2.5 (or in fact, whenever the supported versions of > > Python change). > > > Such information is necessary for extensions, but irrelevant for > > programs or other modules. > > Indeed, the intent was that this strict upper bound would apply to > extensions, not to modules. Not sure if that intent got lost somewhere > along the way. IIRC We did conclude that we need the Provides: pythonX.Y-foo for modules as well and have to regenerate this information if we change the set of supported python versions. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
