Re: Final draft of Python Policy (hopefully ;-)
On Oct 27, Gregor Hoffleit wrote: 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. If nobody find fundamental show-stoppers that render this unusable, we're going to submit it to Debian Policy very soon. My main concern is that the policy seems to force the installation of the default version to use anything in the distribution that uses python... a few comments, focusing on section 2: - If a package works with any version of Python in the archive, is there a setup that allows users to choose which version of Python they want to have installed? Or are they stuck with the default version? - If not, how is /usr/bin/python going to be handled? We threw out using an alternative for it, but that was when we were still calling the default version python-base. If the default version isn't installed, presumably /usr/bin/python doesn't exist under the current setup. What do you use for a #! then? - Why is the following statement in the policy (2.1.1)? You should not make a default, unversioned module package python-foo depend on the versioned Python package pythonX.Y! 'Depends: pythonX.Y' appears to be synonymous to 'Depends: python (= X.Y), python ( X.Y+1)'. Is this some sort of newbie-friendliness we're going for? If so, why? The only good reason I can think of is to have a parallel between the python-foo/python and pythonM.N-foo/pythonM.N names. But since that's rather user-invisible (it's a dependency), I don't quite see the point. - Should 2.1.1 require python-foo to provide pythonX.Y-foo? - Again in 2.1.1: Should any new python-foo conflict with python-base (= 1.5.2-18.4) so python-base has to be upgraded for python-foo to be upgraded too? (Could this get rid of the whole conficts problem in python core?) - Would it be cleaner to make all pythonX.Y-foo provide python-foo, so any version-independent package that needs foo can depend on python-foo? If we did this (and got rid of the Depends funkiness) we could throw out 2.1.1 completely, as it would be a special case of 2.1.2. - 2.1.2.2, or some other part of the policy, should explicitly prohibit the use of /usr/lib/site-python, as it is deprecated upstream. - I'm not sure in 2.1.2.2 that /usr/lib/python/site-packages is a good name... maybe /usr/share/python/site-packages instead. (After all, the things should be arch independent.) I'd be happy to code up the symlink thingamajig for 2.1.2.2 if nobody's working on it. - Perhaps instead of a dependency on python (= X.Y+1), 2.1.2.2 should say packages should confict with python ( X.Y+1), unless we want to force everyone to have the default version installed. - Maybe the rationale should be at the beginning of section 2... it would make the rest of the section more understandable. - (editorial nit) There seems to be a superfluous in the rationale. Anyway, feel free to rip away... Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/
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: Final draft of Python Policy (hopefully ;-)
Chris Lawrence writes: - I'm not sure in 2.1.2.2 that /usr/lib/python/site-packages is a good name... maybe /usr/share/python/site-packages instead. (After all, the things should be arch independent.) I'd be happy to code up the symlink thingamajig for 2.1.2.2 if nobody's working on it. See 1.4: It's still in sys.path, but it's use is deprecated.
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
FYI: Mail to python package maintainers
I sent the following mail Python-2.1 becoming Debian's default Python ^version to each maintainer probably affected by the switch to the new Python version: You get this mail, because you are the maintainer of packages probably affected by the change of the Python version. Followups and replies, which could be of interest for all Python packagers, should be sent to [EMAIL PROTECTED] Your packages are: maintainer's package list What happened? In the past months, we had several discussions about different versions of Python in Debian, and how to make upgrades between different versions. You can read it in the archives of the debian-python mailing list (http://lists.debian.org/debian-python/2001/). The discussions led to a proposed python policy. The current version 0.3.7 can be found at http://ftp-master.debian.org/~doko/python/python-policy.txt Newer versions may exist at http://people.debian.org/~flight/python/. We prepared python packages, which follow this policy and which make Python 2.1 the default Python version in Debian. These packages can be found at: deb http://ftp-master.debian.org/~doko/python ./ Where do we head? We want to upload these new packages to unstable on Tuesday (2001-10-30) or Wednesday (2001-10-31). Because most of the python dependent packages in Debian have unversioned dependencies on the python version, you will have to set the new python packages on hold, until you have verified, that they work with the new python version. If it is necessary to ship the next Debian release with python1.5, we will do. We will not ship with the python2.0 packages, as all these packages cn be converted to use version 2.1. There are 2.2 beta packages in unstable, but not as the default, because the final 2.2 version is not yet released. What changed with the new packages? - The python-base package is gone. We have no package providing python-base, because we simply do not know, if a package is compatible with version 2.1. So for the simplest case, a package maintainer should check, if his package works with 2.1, and then replace the dependency on python-base with: Depends: python (= 2.1), python ( 2.2). If the package does not work with the new version, the package should depend on python1.5 and scripts must call the interpreter 'python1.5' explicitely. This will lead to a short period of instability in unstable, but should be resolveable within a week. - See the Appendix B of the python-policy for an upgrade path. Need some help? We will prepare NMUs for packages, which are maintained by the Debian-QA team. If I am asked for and my time allows it, I am willing to make NMUs for other packages as well (or better: directly ask on debian-python@lists.debian.org). If you want to build packages for the new schema, there is a group writeable directory on ftp.master.debian.org: ~doko/www/python-uploads, where you could place your newly built packages. I will copy these packages to incoming together with the new Python packages. We hope to make a smooth upgrade from 1.5 to 2.1 and provide a current Python version with bells, whistles and packages for woody. Matthias Klose (and Gregor Hoffleit).
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
Packaging python-egenix-mx*
Hi, I have now finished Debianizing eGenix mx BASE (based on patch done by Federico Di Gregorio, see bug#56): http://www.lemburg.com/files/python/eGenix-mx-Extensions.html The upstream maintainer of the mx packages (mxdatetime, mxstack, mxtools, ...) now distributes everything in one source package, so I have used egenix-mx-base as source package name. It currently builds the following binary packages compiled for Python 2.1: python-egenix-mxbeebase python-egenix-mxdatetime (new version of python-mxdatetime) python-egenix-mxproxy python-egenix-mxqueue python-egenix-mxstack (new version of python-mxstack) python-egenix-mxtexttools (new version of python-mxtexttools) python-egenix-mxtools (new version of python-mxtools) and also python-egenix-mx-base-dev which includes headers for the C API to the libraries. Questions: 1. Does anyone need Python 1.5 versions of these packages? Packages I have found that are associated with some of the mx packages are: python-mysqldb (Suggests: python-mxdatetime) python-popy (Depends: python-mxdatetime) python-psycopg (Depends: python-mxdatetime) python-reportlab (Suggests: python-mxtexttools) but I currently assume that no one of those will need Python 1.5. Is my assumption incorrect? 2. Should I build Python 2.2 versions of these packages (i.e. will woody include Python 2.2(beta))? 3. As the policy mandates, I have made the packages depend on python (= 2.1), python ( 2.2) Lintian doesn't really like that. :-) For example: E: python-egenix-mxdatetime: package-has-a-duplicate-relation python N: N: The package seems to declare a relation on another package more than N: once. This is not only sloppy but can break some tools N: Okay, this wasn't a question, just a note. 4. Any other comments? Oh, and if anyone wants to look at or test the packages, get them here: deb http://joel.rosdahl.net/debian/ ./ deb-src http://joel.rosdahl.net/debian/ ./ Regards, Joel -- Joel Rosdahl [EMAIL PROTECTED] (PGP and GPG keys available)
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: Packaging python-egenix-mx*
Federico Di Gregorio writes: On Sun, 2001-10-28 at 22:34, Joel Rosdahl wrote: Questions: 1. Does anyone need Python 1.5 versions of these packages? Packages I have found that are associated with some of the mx packages are: python-mysqldb (Suggests: python-mxdatetime) python-popy (Depends: python-mxdatetime) python-psycopg (Depends: python-mxdatetime) i plan to drop support for 1.5 from psycopg (at least in debian builds) when we'll have a zope for python 2.1 in the archive. python-reportlab (Suggests: python-mxtexttools) but I currently assume that no one of those will need Python 1.5. Is my assumption incorrect? I did look at python-mysqldb and python-reportlab. They can use 2.1. I didn't look at python-popy. 2. Should I build Python 2.2 versions of these packages (i.e. will woody include Python 2.2(beta))? well, woody is not yet frozen, and bug fixes (I read: the final version) are allowed in a freeze. And woody won't release before Christmas (the scheduled release date for python2.2). 3. As the policy mandates, I have made the packages depend on python (= 2.1), python ( 2.2) Lintian doesn't really like that. :-) For example: E: python-egenix-mxdatetime: package-has-a-duplicate-relation python N: N: The package seems to declare a relation on another package more than N: once. This is not only sloppy but can break some tools N: Okay, this wasn't a question, just a note. Which tools are this? Basically the error should prevent something like python (=1.x), python ( 1.y). 4. Any other comments? Oh, and if anyone wants to look at or test the packages, get them here: deb http://joel.rosdahl.net/debian/ ./ deb-src http://joel.rosdahl.net/debian/ ./ looks ok. Would it make sense to add a 'Replaces:' line for those packages without the '-egenix' part? I.E: Package: python-egenix-mxdatetime Replaces: python-mxdatetime Could you copy these packages to ftp-master.debian.org in ~doko/www/python-uploads? Thanks, 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 --
Re: Final draft of Python Policy (hopefully ;-)
G'day, Gregor's already answered most of these, but thought I'd throw in a comment or two. On Sun, Oct 28, 2001 at 12:11:04AM -0500, Chris Lawrence wrote: On Oct 27, Gregor Hoffleit wrote: 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. If nobody find fundamental show-stoppers that render this unusable, we're going to submit it to Debian Policy very soon. My main concern is that the policy seems to force the installation of the default version to use anything in the distribution that uses python... a few comments, focusing on section 2: This is not entirely true... it depends on what modules your application depends on and how the packagers have chosen to package them. If you are lucky, pythonX.Y-module packages (or a version independant 2.1.3/2. package) for all of them exist, in which case you can choose any version X.Y for which all the required packages exist. Note that the policy allows you to create your own pythonX.Y-foo packages if the existing python-foo mantainer chose not to create them. Note you will have to invoke /usr/bin/pythonX.Y, as without the default python package installed /usr/bin/python won't exist. - If a package works with any version of Python in the archive, is there a setup that allows users to choose which version of Python they want to have installed? Or are they stuck with the default version? I might be confusing things a bit here... do you mean an application package, or a module package? For module packages, users can specify what version to use in their own scripts with an appropriate #!/usr/bin/pythonX.Y. For application packages, the user is bound to whatever version of Python the packager chose. This can be a particular version using Depends: pythonX.Y and #!/usr/bin/pythonX.Y, or the default using Depends: python and #!/usr/bin/python. Note that a packager _can_ give the end user some degree of control over what version of python is used by using #!/usr/bin/env python. This allows the end user to put whatever they like as python in /usr/local/bin. However, this is risky as it bypasses all the dependancy checking. I suspect that package mantainers using this trick will stop after a few bug reports from people installing beta's in their own /usr/local :-) - Should 2.1.1 require python-foo to provide pythonX.Y-foo? probably a good idea. I can see no reason not to, and allows packages to depend on pythonX.Y, pythonX.Y-foo so that they can still work when python and python-foo are upgraded, and a backwards compatible pythonX.Y-foo released. -- -- ABO: finger [EMAIL PROTECTED] for more info, including pgp key --
Re: Packaging python-egenix-mx*
G'day, On Sun, Oct 28, 2001 at 10:34:05PM +0100, Joel Rosdahl wrote: Hi, I have now finished Debianizing eGenix mx BASE (based on patch done by Federico Di Gregorio, see bug#56): http://www.lemburg.com/files/python/eGenix-mx-Extensions.html The upstream maintainer of the mx packages (mxdatetime, mxstack, mxtools, ...) now distributes everything in one source package, so I have used egenix-mx-base as source package name. It currently builds the following binary packages compiled for Python 2.1: python-egenix-mxbeebase python-egenix-mxdatetime (new version of python-mxdatetime) python-egenix-mxproxy python-egenix-mxqueue python-egenix-mxstack (new version of python-mxstack) python-egenix-mxtexttools (new version of python-mxtexttools) python-egenix-mxtools (new version of python-mxtools) and also python-egenix-mx-base-dev [...] 3. As the policy mandates, I have made the packages depend on python (= 2.1), python ( 2.2) [...] 4. Any other comments? [...] My only suggestion is, if you are at all in doubt about supporting multiple versions of python, don't use the 2.1.1 support only the default packaging option, instead use the 2.1.3-1. multiple versioned packages option. Note that even if you choose the multiple versioned packages option, you are not required to support all versions, only the default. This allows you to easily add multiple version support later on if you wish. It actualy gives you multiple version support for free as you produce new packages, as each new version doesn't break your old packages. It might seem like more work initially, but I'm sure in the long run it will work out easier. -- -- ABO: finger [EMAIL PROTECTED] for more info, including pgp key --
