[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Final draft of Python Policy (hopefully ;-)



G'day, 

Gregor's already answered most of these, but thought I'd throw in a comment
or two.

On Sun, Oct 28, 2001 at 12:11:04AM -0500, Chris Lawrence wrote:
> 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:

This is not entirely true... it depends on what modules your application
depends on and how the packagers have chosen to package them. If you are
lucky, pythonX.Y-<module> packages (or a version independant 2.1.3/2.
package) for all of them exist, in which case you can choose any version X.Y
for which all the required packages exist. Note that the policy allows you
to create your own pythonX.Y-<foo> packages if the existing python-<foo>
mantainer chose not to create them.

Note you will have to invoke /usr/bin/pythonX.Y, as without the default
python package installed /usr/bin/python won't exist.

> - 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?

I might be confusing things a bit here... do you mean an application
package, or a module package? 

For module packages, users can specify what version to use in their own
scripts with an appropriate "#!/usr/bin/pythonX.Y". For application
packages, the user is bound to whatever version of Python the packager
chose. This can be a particular version using "Depends: pythonX.Y" and
"#!/usr/bin/pythonX.Y", or the default using "Depends: python" and
"#!/usr/bin/python".

Note that a packager _can_ give the end user some degree of control over
what version of python is used by using "#!/usr/bin/env python". This allows
the end user to put whatever they like as python in /usr/local/bin. However,
this is risky as it bypasses all the dependancy checking. I suspect that
package mantainers using this trick will stop after a few bug reports from
people installing beta's in their own /usr/local :-)

> - Should 2.1.1 require python-foo to provide pythonX.Y-foo?

probably a good idea. I can see no reason not to, and allows packages to
depend on pythonX.Y, pythonX.Y-foo so that they can still work when
python and python-foo are upgraded, and a backwards compatible pythonX.Y-foo
released.

-- 
----------------------------------------------------------------------
ABO: finger abo@minkirri.apana.org.au for more info, including pgp key
----------------------------------------------------------------------



Reply to: