Re: (2nd try) Final draft of Python Policy (hopefully ;-)
Jérôme Marant writes:
> Gregor Hoffleit <gregor@hoffleit.de> writes:
>
> > 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.
>
> I've asked some questions to Matthias in private yesterday because I
> didn't have enough time to follow all recent threads and question.
> So, some of the questions may have already been asked.
[didn't read my mail yesterday ...]
> 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).
> + 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
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
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.
> + Do we really need to use python-base and al. packages except for
> the transtion?
>
> Or maybe for python version independent modules?
>
> + Mainly I don't see the reason for this "support for default version"
> case.
In the ideal case, we ship a Debian release with one Python version
(the default). We may have to support older/new python versions for
packages requiring these Python versions.
> 2.1.3
>
> 1.
>
> + Is pythonX.Y-module the same thing as python-api defined by Neil?
should be pythonX.Y-foo. Changed.
> + 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.
> Now, the concrete case of python-xml. If I also want to ship a
> version for 1.5. If I undestood correctly the document, I'll have
> this :
>
> -=-=-=-=-=-=-=
>
> python2.1-xml
> Depends: libc6 (>= 2.2.3-7), python2.1-base, python2.1-xmlbase
>
> python-xml
> Depends: python (>= 2.1), python (<< 2.2), python2.1-module
s/module/xml/; s/python2.1-base/python2.1/
> [I guess that some dependancies are missing there, but i'm following the
> document.
> Maybe adding python2.1-xml?
>
> ]
>
> python1.5-xml
> Depends: libc6 (>= 2.2.3-7), python1.5-base
s/python1.5-base/python1.5/
> -=-=-=-=-=-=-
So basically these are the correct dependencies.
> 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.
> I think that we should include a section about maintainers scripts
> for python modules.
Ok. I will add one (with the example scripts in the appendix).
Reply to: