Re: (2nd try) Final draft of Python Policy (hopefully ;-)
Jérôme Marant writes:
> 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?
It already exists:
deb http://ftp-master.debian.org/~doko/python ./
> > 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.
So you simply set the new python packages on hold, until all packages
you need are converted. What's wrong with this approach?
> > 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".
There's nothing problematic. See 3./3.2 of the policy.
> > 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.
sorry, I don't understand this argument.
> > > + 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.
we proposed not to support 2.0 anymore, yes.
> 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?
python-xml and python-newt are the only modules, that some base
packages depend on (boot-floppies and reportbug). So IMO we need to
have at least packages python1.5-xml and python1.5-newt (NMU
prepared). 'base' is already frozen, so we should not force an upgrade
to 2.1 for these packages (if we see, that the packages work, we can
depend them on 2.1 later).
So my propsal would be: make a python1.5-xml package (separate source
package), and one of:
- a python-xml package (for 2.1)
- a python-xml (2.1), a python2.2-xml package
- a python-xml (2.1), a python2.1-xml, a python2.2-xml package
Reply to: