Re: Final draft of Python Policy (hopefully ;-)
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 <lawrencc@debian.org> - http://www.lordsutch.com/chris/
Reply to: