Matthias Klose <[EMAIL PROTECTED]> 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閞鬽e Marant <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://marant.org