Re: (2nd try) Final draft of Python Policy (hopefully ;-)
Matthias Klose <doko@cs.tu-berlin.de> writes:
> > 2.1.1 Support Only The Default Version
> >
> > + does this "Depends: python (>= X.Y), python (<< X.Y+1)" really
> > work since versioned provides do not exist yet? Isn't it
> > python-base rather than python ?
>
> yes. python is a real package now. It is a replacement for python-base
> (but it conflicts with python-base).
What does a real package mean for you? I've looked through the whole
package list and I didn't find any "python" package.
"python" is currently a virtual package provided by python-base.
So I don't understand how version comparisons can work without
versioned provides.
Or maybe is it something planned?
>
> > + a new change to the major version of python, will make all
> > packages depending on the default version being uninstalled, right?
> > If so, I don't think it is the Right Thing.
>
> s/major//. Correct. Assume we release woody with python (2.1), and we
But I don't want all my python packages to be uninstalled because
python changed. This is unacceptable.
> release woody+1 with python (2.4). Then we have to make sure, that a
> dist-upgrade doesn't break anything. That's doable. Now we replace
> python (2.1) with python (2.3) in unstable. You see, that the new
> version breaks the old one. But only as long as the packages are
The problematic thing here is programs containing "#!/usr/bin/env python".
> upgraded to use the new version as well.
>
> > + I think that "Depends: python<X>.<Y>" would work better and avoid
> > breaking things.
>
> Using python-foo with the new python version would be still broken.
> Basically your proposal is 2.1.2.
Yes it is. But if you upload a new version of Python as "python",
nothing will be broken. I would say that "python" is fine for
those using apt-get install python but I still doubt that it is
a good thing to use it in dependencies.
> > + I don't see the need for a "default package python-<foo>" there
> > What for is it meant to be used?
>
> It let's a package depend on:
>
> python (>= 2.1), python (<< 2.2), python-foo
>
> and can expect a working default Python version, which has support for
> python-foo.
Yes, it is fine for the user as I said previously.
...
> > python-xml
> > Depends: python (>= 2.1), python (<< 2.2), python2.1-module
>
> s/module/xml/; s/python2.1-base/python2.1/
...
> > Have all these packages to be built with the same source?
>
> No. Although it avoids source code duplication, it makes it more
> difficult to remove an older version. My proposal would be to build
> 1.5 and 2.0 packages from one source and 2.1 and 2.2 packages from
> another source package, so the first source package and binary
> packages can easily be removed.
We do not support 2.0 any more, BTW.
What about python-xml? Does it have to be build with python2.1-xml
and generally always with the newest python version of the package?
Thanks.
--
Jérôme Marant <jerome.marant@free.fr>
<jerome@marant.org>
http://marant.org
Reply to: