Re: Final draft of Python Policy (hopefully ;-)
Chris Lawrence writes:
> 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:
Partly. You have to install the default version. You are free to
install any other Python version. A package is allowed to use these
other versions (although we would like to see it to use the default
version).
> - 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?
They are "stuck" with the default version. If you want to experiment
how your package works with different versions, use dpkg-divert.
Please remember: Debian is not a "Distribution for Python Development
and Porting supporting multiple versions of Python".
> - 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?
s/python-base/python/.
/usr/bin/python is in the `python' package. Interesting question not
to install the default version, but another question: Then you cannot
rely on /usr/bin/python beeing existent. But then your package should
use pythonX.Y for the interpreter name anyway.
> - 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?
assume, we have python (1.5) (providing the python link), and package
python-foo depending on python1.5. python-foo calls the python
interpreter with '#! python'. Noe we upgrade to python
(2.1). python-foo still depends on python1.5, but the python1.5
interpreter is available under the name python1.5. So your package may
break. On the other hand, depending on python (>= X.Y), python (<< X.Y+1)
breaks your package intentionally. So a package maintainer has to
acknowledge the package works with the new version and upgrade the
dependency.
If you do have such a trivial application, which doesn't install
python modules and doesn't rely on version specifics, you still can
depend on python (>= some-version).
> - Should 2.1.1 require python-foo to provide pythonX.Y-foo?
Interesting. Yes, that would make package names more orthogonal. Are
we allowed to add all these virtual packages according to the Debian
policy?
> - 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?)
See my 18.6 packages at
deb http://ftp-master.debian.org/~doko/python ./
pyhton-base becomes python, the new package conflicts with
python-base.
> - 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.
No. Assume you install python1.5-foo providing python-foo and
python2.1-bar providing python-bar. A package depending on python-foo
and -bar won't work.
> - 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'l add it.
> - 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.
And what about binary dependent site packages?
I am not sure, why Gregor re-added /usr/lib/site-python ...
Anyway, Gregor wanted to discuss the move to /usr/share with upstream,
before we are going to provide it in the Debian packages. We should
add a section 'Open Issues' at the end...
> - 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.
2.1.3.2? Not (>= X.Y+1)? Where is the difference. In both cases you
specify, that your package doesn't work with the next upstream
version.
> - Maybe the rationale should be at the beginning of section 2... it
> would make the rest of the section more understandable.
agreed. Hope you get the section number right after the change ;-)
> - (editorial nit) There seems to be a superfluous < in the rationale.
Corrected.
> Anyway, feel free to rip away...
Not at all. Thanks for the feedback.
Matthias
Reply to: