Re: Where is the Debian Python Policy?
On Sun, Feb 10, 2002 at 10:26:26AM +0100, Matthias Klose wrote: Donovan Baarda writes: G'day, just thought I'd have another look at the current policy and I couldn't find it. Where is it again? /usr/share/doc/python, anybody actually reading the docs? Ahh, it's included in the python package now. I was actually refering to the online copy that was put up during the discussion that developed it. Can we get a link to it put on the Debian devel page? http://www.debian.org/devel/ IMO that makes no sense as long as it is not part of the Debian policy (which will not happen for woody) Huh? If it's included in the python package that is included in woody with a title python-policy.txt, doesn't that sorta make it part of the Debian policy for woody? -- -- ABO: finger [EMAIL PROTECTED] for more info, including pgp key --
Where is the Debian Python Policy?
G'day, just thought I'd have another look at the current policy and I couldn't find it. Where is it again? Can we get a link to it put on the Debian devel page? http://www.debian.org/devel/ -- -- ABO: finger [EMAIL PROTECTED] for more info, including pgp key --
pure python modules - Python Policy 2.2.3
Hello Pythoneers, another version of the dh_purepython script is online at http://people.debian.org/~calvin/purepython/. It provides support for Section 2.2.3 of the Python Policy which adresses version-independent Python modules. I would be pleased to hear any comments and/or suggestions from you. In short: to use dh_purepython, your package must have 1) Depends: python or if you require a specific minimal version X.Y: Depends: python (= X.Y) 2) If you use Python Distutils to package your module (which is recommended), you must have Build-Depends: pythonX.Y-dev XXX It should not be mandatory to build-depend on all pythonX.Y-dev versions. But you should test your module with multiple Python versions. 3) installed all .py files into /usr/lib/python/site-packages/. 4) no conflict with future Python versions. It is not supported that your package works with Python 2.1, but not with 2.2 and above. A pythonX.Y package must have 1) a postinst script to byte-compile all previously installed packages who use dh_purepython 2) a prerm script to remove byte-compiled files from all previously installed packages who use dh_purepyton I have untested scripts python.postinst and python.prerm for this. Greetings, Bastian pgp2v7TntChEV.pgp Description: PGP signature
Re: pure python modules - Python Policy 2.2.3
On Sun, Jan 13, 2002 at 03:48:40PM +0100, Bastian Kleineidam wrote: A pythonX.Y package must have 1) a postinst script to byte-compile all previously installed packages who use dh_purepython 2) a prerm script to remove byte-compiled files from all previously installed packages who use dh_purepyton I have untested scripts python.postinst and python.prerm for this. If you ask me, scripts for that should go into the python package so that not every python-xxx package has to carry them itself. Something like /usr/lib/python/new-module $(pkgname) should do all the preprocessing. Gregor, what do you think: Is this doable/practical? cu Torsten pgpjYaNJGCoJY.pgp Description: PGP signature
Re: pure python modules - Python Policy 2.2.3
Torsten Landschoff writes: On Sun, Jan 13, 2002 at 03:48:40PM +0100, Bastian Kleineidam wrote: I have untested scripts python.postinst and python.prerm for this. If you ask me, scripts for that should go into the python package so that not every python-xxx package has to carry them itself. Something like /usr/lib/python/new-module $(pkgname) should do all the preprocessing. the python package may not yet be configured, before a package uses it for registration.
Re: pure python modules - Python Policy 2.2.3
On Sun, Jan 13, 2002 at 09:32:58PM +0100, Matthias Klose wrote: If you ask me, scripts for that should go into the python package so that not every python-xxx package has to carry them itself. Something like /usr/lib/python/new-module $(pkgname) should do all the preprocessing. the python package may not yet be configured, before a package uses it for registration. If the package module package depends on python (as it has to anyway) dpkg will configure python before the module in any case (safe circular dependencies). So this is not an issue. Apart from that, it would suffice to drop the scripts into the filesystem. If a maintainer script of the module package can call /usr/bin/python .../compileall.py directly I see no reason why it should not be able to do this through a wrapper (which could even remember which source files are compiled so that python2.3 when available can automatically recompile all modules). Am I missing something? Torsten pgpzgUm7WEvSB.pgp Description: PGP signature
lintian and new python policy
Has anyone started modifying lintian? If I remember correctly, packages that generate lintian errors will be rejected... At the moment, lines like Depends: python1.5 cause an error, E: python-script-but-no-python-dep Also, someone else reported that lintian complains against Depends: python (= 2.1), python ( 2.2) Should the policy be changed to recommend: Depends: python (= 2.1) Conflicts: python (= 2.2) instead two deps on python? Or is two deps on python not a problem with new dpkg, apt etc? -- Tom Cato Amundsen [EMAIL PROTECTED] GNU Solfege - free eartraining, http://www.gnu.org/software/solfege/ pgpKI6Ssn8AaT.pgp Description: PGP signature
Re: lintian and new python policy
On Mon, Oct 29, 2001 at 12:40:33PM +0100, Tom Cato Amundsen wrote: Has anyone started modifying lintian? If I remember correctly, packages that generate lintian errors will be rejected... Lintian is advisory only. Also, someone else reported that lintian complains against Depends: python (= 2.1), python ( 2.2) This is a lintian bug. It's not bothering to notice that one's a less-than and the other's a greater-than. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Security here. Yes, maam. Yes. Groucho glasses. Yes, we're on it. C'mon, guys. Somebody gave an aardvark a nose-cut: somebody who can't deal with deconstructionist humor. Code Blue. -- Mike Hoye, see http://azure.humbug.org.au/~aj/armadillos.txt
Re: lintian and new python policy
Also, someone else reported that lintian complains against Depends: python (= 2.1), python ( 2.2) This is a lintian bug. It's not bothering to notice that one's a less-than and the other's a greater-than. Btw, isn't this Depends line problematic anyway? I could have python 1.5 and 2.2 simultaneously installed and the depends would be satisfied without achieving what the maintainer really wants (i.e. python 2.1). Ben.
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
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 --
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 --
Final draft of Python Policy (hopefully ;-)
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. Gregor
Re: Proposed modification to the Python Policy
Matthias Klose [EMAIL PROTECTED] writes: Jérôme Marant writes: I do propose that we install all architecture independant modules in /usr/share and all architecture dependent modules in /usr/lib as it has always been. assume we have a package with an architecture independant module and an architecture dependent module. Then we have to split it in share and lib? ugly. And it's unsupported upstream by distutils. I made a mistake: i should have said files rather than modules. No need to split the package. This would make sense IMHO. (BTW, Brendan O'Dea did the same with perl). For instance, all lib-dynload files would go to /usr/lib and all .py would go to /usr/share With distuptils, you can do that with some options among the following: Options for 'install' command: --prefixinstallation prefix --exec-prefix (Unix only) prefix for platform-specific files --home (Unix only) home directory to install under --install-base base installation directory (instead of --prefix or -- home) --install-platbase base installation directory for platform-specific files (instead of --exec-prefix or --home) --root install everything relative to this alternate root directory --install-purelib installation directory for pure Python module distributions --install-platlib installation directory for non-pure module distributions --install-lib installation directory for all module distributions (overrides --install-purelib and --install-platlib) I don't see this proposal as necessary for the transition from 1.5 to 2.1, so I would like to see it not as part of the policy during the transition. No, this is not necessary but as we are writing the Policy, I would like to see it for the near future. I am personaly ready to implement this in my packages. Cheers, -- Jérôme Marant [EMAIL PROTECTED] [EMAIL PROTECTED] http://marant.org
Re: [Draft] Debian Python Policy 0.2
On Wed, Oct 10, 2001 at 10:28:58AM -0700, Neil Schemenauer wrote: Anthony Towns wrote: Hrm. That doesn't seem to make sense. For example, Python 2.1 supports the Python 2.0 API completely, and Python 2.2 supports the Python 2.1 API completely too, doesn't it? API in this context means binary API. Only Python 2.1.X supports the 2.1 API. The point is probably moot anyhow since I've almost finished creating packages using the scheme proposed by Donavon and others. I need to update the policy and doing some more testing yet though. Which scheme was that? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Security here. Yes, maam. Yes. Groucho glasses. Yes, we're on it. C'mon, guys. Somebody gave an aardvark a nose-cut: somebody who can't deal with deconstructionist humor. Code Blue. -- Mike Hoye, see http://azure.humbug.org.au/~aj/armadillos.txt pgpJ19LhlTsFQ.pgp Description: PGP signature
Re: [Draft] Debian Python Policy 0.2
On Sun, Sep 30, 2001 at 01:52:00PM -0700, Neil Schemenauer wrote: Donovan Baarda wrote: Hmmm, but if only python can provide python-api-*, then any packages that depend on python-api-X.Y will be broken when a new version of python providing python-api-X.Z comes out, and no python-X.Y package can be compatible with it. Hrm. That doesn't seem to make sense. For example, Python 2.1 supports the Python 2.0 API completely, and Python 2.2 supports the Python 2.1 API completely too, doesn't it? Or something almost to that effect, if you consider the 2.1 API to be the set of non-deprecated functions supported by python 2.1, or similar. Having Python 2.1 look in /usr/lib/python2.[01] and Provide: python-api-2.0, python-api-2.1 might adequately express this, and ease upgrade problems. That's right. Packaged modules must be updated when a new version of Python is installed. It would be a shame if the packaging system declared some combinations of packages broken, even though in actual fact they would/could work fine. It'll be more of a shame is python is a continual source of problems as far as porting (oh no! everything python related must be rebuilt right now!) or the unstable-testing process is concerned. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Freedom itself was attacked this morning by faceless cowards. And freedom will be defended.'' Condolences to all involved. pgpupj2aUkgOZ.pgp Description: PGP signature
Re: [Draft] Debian Python Policy 0.2
The point is probably moot anyhow since I've almost finished creating packages using the scheme proposed by Donavon and others. I need to update the policy and doing some more testing yet though. That's good news. I'm itching to try out some of the new features. Would I be able to assist in testing your packages? Ciao, Gordon
Re: [Draft] Debian Python Policy 0.2
Donovan Baarda wrote: Hmmm, but if only python can provide python-api-*, then any packages that depend on python-api-X.Y will be broken when a new version of python providing python-api-X.Z comes out, and no python-X.Y package can be compatible with it. That's right. Packaged modules must be updated when a new version of Python is installed. Neil
