On Oct 27, Gregor Hoffleit wrote: > I've put a version 0.3.6 of the Python Policy Draft on > http://people.debian.org/~flight/python/. The version is still a little > bit rough and sometimes incomplete, but it already gives a good outline > of the Python packaging system we are installing just now. > > Please have a look at the document, and post all fundamental problems > you have with the content. > > If nobody find fundamental show-stoppers that render this unusable, > we're going to submit it to Debian Policy very soon.
My main concern is that the policy seems to force the installation of the default version to use anything in the distribution that uses python... a few comments, focusing on section 2: - If a package works with any version of Python in the archive, is there a setup that allows users to choose which version of Python they want to have installed? Or are they stuck with the default version? - If not, how is /usr/bin/python going to be handled? We threw out using an alternative for it, but that was when we were still calling the default version "python-base". If the default version isn't installed, presumably /usr/bin/python doesn't exist under the current setup. What do you use for a #! then? - Why is the following statement in the policy (2.1.1)? "You should not make a default, unversioned module package python-foo depend on the versioned Python package pythonX.Y!" 'Depends: pythonX.Y' appears to be synonymous to 'Depends: python (>= X.Y), python (<< X.Y+1)'. Is this some sort of newbie-friendliness we're going for? If so, why? The only "good reason" I can think of is to have a parallel between the python-foo/python and pythonM.N-foo/pythonM.N names. But since that's rather user-invisible (it's a dependency), I don't quite see the point. - Should 2.1.1 require python-foo to provide pythonX.Y-foo? - Again in 2.1.1: Should any new python-foo conflict with python-base (<= 1.5.2-18.4) so python-base has to be upgraded for python-foo to be upgraded too? (Could this get rid of the whole conficts problem in python core?) - Would it be cleaner to make all pythonX.Y-foo provide python-foo, so any version-independent package that needs foo can depend on python-foo? If we did this (and got rid of the Depends funkiness) we could throw out 2.1.1 completely, as it would be a special case of 2.1.2. - 2.1.2.2, or some other part of the policy, should explicitly prohibit the use of /usr/lib/site-python, as it is deprecated upstream. - I'm not sure in 2.1.2.2 that /usr/lib/python/site-packages is a good name... maybe /usr/share/python/site-packages instead. (After all, the things should be arch independent.) I'd be happy to code up the symlink thingamajig for 2.1.2.2 if nobody's working on it. - Perhaps instead of a dependency on python (<= X.Y+1), 2.1.2.2 should say packages should confict with python (>> X.Y+1), unless we want to force everyone to have the default version installed. - Maybe the rationale should be at the beginning of section 2... it would make the rest of the section more understandable. - (editorial nit) There seems to be a superfluous < in the rationale. Anyway, feel free to rip away... Chris -- Chris Lawrence <[EMAIL PROTECTED]> - http://www.lordsutch.com/chris/