Re: (2nd try) Final draft of Python Policy (hopefully ;-)
Gregor Hoffleit [EMAIL PROTECTED] 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. 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 ? + 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. + I think that Depends: pythonX.Y would work better and avoid breaking things. + 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. 2.1.3 1. + Is pythonX.Y-module the same thing as python-api defined by Neil? + I don't see the need for a default package python-foo there What for is it meant to be used? 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 [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 -=-=-=-=-=-=- Have all these packages to be built with the same source? If nobody find fundamental show-stoppers that render this unusable, we're going to submit it to Debian Policy very soon. I think that we should include a section about maintainers scripts for python modules. Thanks. -- Jérôme Marant [EMAIL PROTECTED] [EMAIL PROTECTED] http://marant.org
Re: (2nd try) Final draft of Python Policy (hopefully ;-)
Jérôme Marant writes: Gregor Hoffleit [EMAIL PROTECTED] 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: pythonX.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).
Re: (2nd try) Final draft of Python Policy (hopefully ;-)
Matthias Klose [EMAIL PROTECTED] writes: 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. You mean python, python-foo I presume? 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. Why is this easier or better than uploading a new version of the source package that just builds 2.1 and 2.2 packages? Joel -- Joel Rosdahl [EMAIL PROTECTED] (PGP and GPG keys available)
Re: (2nd try) Final draft of Python Policy (hopefully ;-)
Joel Rosdahl writes: Matthias Klose [EMAIL PROTECTED] writes: 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. You mean python, python-foo I presume? You may want to do this, if you _know_ that your packages work with python2.4 and python3 as well. 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. Why is this easier or better than uploading a new version of the source package that just builds 2.1 and 2.2 packages? If you support 2.1 and 2.2 only, yes, then it's easiser :) Matthias
Re: (2nd try) Final draft of Python Policy (hopefully ;-)
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: pythonX.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 [EMAIL PROTECTED] [EMAIL PROTECTED] http://marant.org
Re: (2nd try) Final draft of Python Policy (hopefully ;-)
Gregor Hoffleit [EMAIL PROTECTED] writes: If nobody find fundamental show-stoppers that render this unusable, we're going to submit it to Debian Policy very soon. I think we could also add a section about how to use distutils to install things in the right place. My 2 eurocents, Cheers, -- Jérôme Marant [EMAIL PROTECTED] [EMAIL PROTECTED] http://marant.org
Re: (2nd try) Final draft of Python Policy (hopefully ;-)
Jérôme Marant writes: 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? 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: pythonX.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
Re: (2nd try) Final draft of Python Policy (hopefully ;-)
From Appendix B.2: The new packages will conflict with every Python dependent package, that does depend on `python', `python-base', without depending on `python ( 1.6)' or `python-base ( 2.1)'. Since the new packages conflict with python-base itself, they don't need to conflict with packages that depend on python-base. I think the first `python-base' needs to be removed. -- Carey Evans http://home.clear.net.nz/pages/c.evans/ Ha ha! Puny receptacle!
Re: (2nd try) Final draft of Python Policy (hopefully ;-)
Matthias Klose [EMAIL PROTECTED] writes: It already exists: deb http://ftp-master.debian.org/~doko/python ./ So, it will exist soon. 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? It is wrong because people will have to put their packages on hold: not everyone is familiar with holding packages. And if they use daily upgrades or dist-upgrades, they can be surprised to see the packages they are using everyday being removed. This won't happen if the package depends on a precise version of python: the upload of the new python can happen without any problem and the module maintainer will change dependencies on this new python, so modules packages will be smoothly upgraded. 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 What are the pro and the cons for each one? (except from 2.2 is not out yet)? Could we decide on this through the policy? Thanks. -- Jérôme Marant [EMAIL PROTECTED] [EMAIL PROTECTED] http://marant.org
Re: (2nd try) Final draft of Python Policy (hopefully ;-)
Carey Evans writes: From Appendix B.2: The new packages will conflict with every Python dependent package, that does depend on `python', `python-base', without depending on `python ( 1.6)' or `python-base ( 2.1)'. Since the new packages conflict with python-base itself, they don't need to conflict with packages that depend on python-base. I think the first `python-base' needs to be removed. hmm, I should reword this: The new packages will conflict with every Python dependent package, that does depend on `python', but not on python ( 1.6) or that does depend on python-base.
Re: (2nd try) Final draft of Python Policy (hopefully ;-)
Jérôme Marant writes: Matthias Klose [EMAIL PROTECTED] writes: 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? It is wrong because people will have to put their packages on hold: not everyone is familiar with holding packages. This will happen in unstable only for a period of one week. You won't see this in testing. People running unstable should expect some breakage for a limited time. We minimize the time of unstability be letting maintainers know when the upgrade will happen. Why the heck do we have unstable? And if they use daily upgrades or dist-upgrades, they can be surprised to see the packages they are using everyday being removed. This won't happen if the package depends on a precise version of python: the upload of the new python can happen without any problem and the module maintainer will change dependencies on this new python, so modules packages will be smoothly upgraded. so please explain us how you would do the upgrade. On the current packages we do have _unversioned_ dependencies. So my propsal would be: make a python1.5-xml package (separate source package), and one of: - a python-xml package (for 2.1) pro: package maintainer only needs to support one version. con: you only support one version. - a python-xml (2.1), a python2.2-xml package - a python-xml (2.1), a python2.1-xml, a python2.2-xml package basically the same, I would prefer the latter if you think that python2.1-xml will need to stay if we switch to 2.2. What are the pro and the cons for each one? (except from 2.2 is not out yet)? Could we decide on this through the policy? No. We could decide that you need at least to provide the package for the default version ;-) Personally I would like to see basic modules be provided for each python version available in Debian. Matthias
Re: (2nd try) Final draft of Python Policy (hopefully ;-)
On Sun, Oct 28, 2001 at 02:57:15PM +0100, Jérôme Marant wrote: Matthias Klose [EMAIL PROTECTED] writes: 2.1.1 Support Only The Default Version [...] + 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. So choose one of the other alteratives available in the policy :-) The beauty is there are three different ways of making packages, each with different benefits and drawbacks. The support only the default version option is IMHO a bad option for most packages, but some people might like it for their packages. It's biggest drawback is packages using it _must_ be upgraded when Python upgrades. It's other drawback is it doesn't automaticly leave you with pythonX.Y-foo packages to support older versions of Python. Instead these have to be made _after_ python-foo has been fixed to support the new version of Python. However, people might like using it when they want only one python-foo package that will definitely break for a different version of Python. For people who have a package that meets this criteria, it is better to have the old packages uninstalled when python changes than to have everything that uses them mysteriosly stop working. -- -- ABO: finger [EMAIL PROTECTED] for more info, including pgp key --
