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]
