Re: Wiki: Debian Python Policy docu not on team site
Hi, I added in the Wiki [0], the link to the python3-defaults docs and policy [1]. Please review it. [0] https://wiki.debian.org/Teams/PythonTeam#preview [1] https://www.debian.org/doc/packaging-manuals/python-policy/ Cheers Emmanuel
Re: Wiki: Debian Python Policy docu not on team site
Hi! On Fri, Oct 1, 2021 at 7:43 AM wrote: > Hello, > > this is about the wiki page of that team. > https://wiki.debian.org/Teams/PythonTeam > > I accidentally found the "Debian Python Policy documentation". > https://www.debian.org/doc/packaging-manuals/python-policy/ Also we have this Policy [0]. But the python-policy that you mention seems to be part of the docs of python3-defaults package. Should we add it in the DPT wiki? Cheers, Emmanuel [0] https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst > > Looks nice and very important for new team members. > > Maybe it would help if it is linked on the team wiki page. > > Kind > Christian Buhtz > >
Wiki: Debian Python Policy docu not on team site
Hello, this is about the wiki page of that team. https://wiki.debian.org/Teams/PythonTeam I accidentally found the "Debian Python Policy documentation". https://www.debian.org/doc/packaging-manuals/python-policy/ Looks nice and very important for new team members. Maybe it would help if it is linked on the team wiki page. Kind Christian Buhtz
Re: Work on a current Debian Python policy (was: Lintian warnings for Python packaging?)
Le lundi 02 novembre 2009 à 21:22 +1100, Ben Finney a écrit : Is there a silent Debian Python policy drafter out there who would like to step forward? Or is this work now moribund? Bug reports concerning the Python policy have been silently ignored. I’m afraid this will last as long as the reference version is in the python-defaults package. Cheers, -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: Work on a current Debian Python policy
Josselin Mouette j...@debian.org writes: Le lundi 02 novembre 2009 à 21:22 +1100, Ben Finney a écrit : Is there a silent Debian Python policy drafter out there who would like to step forward? Or is this work now moribund? Bug reports concerning the Python policy have been silently ignored. I’m afraid this will last as long as the reference version is in the python-defaults package. (I am reading this to mean “the reference version of the Debian Python policy is in the python-defaults package”.) Okay. Clearly one way for this to improve would be for some of those bug reports to be responded to by the maintainer. In the absence of that, though, what other way forward is there? What would need to change for the reference version of the Python policy to be somewhere else? Just start referring to a different document, or something more? -- \ “The most merciful thing in the world… is the inability of the | `\human mind to correlate all its contents.” —Howard Philips | _o__)Lovecraft | Ben Finney pgpCAdS01pveA.pgp Description: PGP signature
Re: Work on a current Debian Python policy (was: Lintian warnings for Python packaging?)
On Tue, 03 Nov 2009 19:02:21 +0100 Josselin Mouette j...@debian.org wrote: Le lundi 02 novembre 2009 à 21:22 +1100, Ben Finney a écrit : Is there a silent Debian Python policy drafter out there who would like to step forward? Or is this work now moribund? Bug reports concerning the Python policy have been silently ignored. I m afraid this will last as long as the reference version is in the python-defaults package. I'm inclined to agree. How would you suggest such a document be managed? Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Work on a current Debian Python policy
Josselin Mouette j...@debian.org writes: Le lundi 02 novembre 2009 à 21:22 +1100, Ben Finney a écrit : Is there a silent Debian Python policy drafter out there who would like to step forward? Or is this work now moribund? Bug reports concerning the Python policy have been silently ignored. I’m afraid this will last as long as the reference version is in the python-defaults package. (I am reading this to mean “the reference version of the Debian Python policy is in the python-defaults package”.) Okay. Clearly one way for this to improve would be for some of those bug reports to be responded to by the maintainer. In the absence of that, though, what other way forward is there? What would need to change for the reference version of the Python policy to be somewhere else? Just start referring to a different document, or something more? -- \ “The most merciful thing in the world… is the inability of the | `\human mind to correlate all its contents.” —Howard Philips | _o__)Lovecraft | Ben Finney pgpMiLC3LSQGH.pgp Description: PGP signature
Re: Work on a current Debian Python policy
On Wed, Nov 4, 2009 at 2:29 AM, Ben Finney ben+deb...@benfinney.id.au wrote: (I am reading this to mean “the reference version of the Debian Python policy is in the python-defaults package”.) Okay. Clearly one way for this to improve would be for some of those bug reports to be responded to by the maintainer. In the absence of that, though, what other way forward is there? Here. What would need to change for the reference version of the Python policy to be somewhere else? Remove it from http://www.debian.org/doc/packaging-manuals/python-policy/ Remove this page http://python-modules.alioth.debian.org/ (wiki is more up to date) Replace this one with wiki too and remove links. http://python-apps.alioth.debian.org/policy.html Just start referring to a different document, or something more? Point everything to wiki. Update MoinMoin to remove bugs and enable latest features that can become useful for collaboration. In particular: * Add subscription by default feature to policy pages so that everybody who edited page automatically receives updates. This will increase collaboration rate. You may forward these edits here as well. * Upgrade also fixes http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=546905 so that inserting table of content will not be a compromise between layout and technical limitations -- anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Work on a current Debian Python policy (was: Lintian warnings for Python packaging?)
Luca Falavigna dktrkr...@debian.org writes: Scott Kitterman ha scritto: Since we currently lack anything like a maintained Python policy, I think this is putting the cart before the horse. […] […] we could wait for the new policy to be drafted, I'm not sure when this will happen, though. I don't know if anyone has even taken the reins for this recently. The last time I knew someone was actually developing a Debian Python policy was when Manoj Srivastava was drafting a document to help record some of the ad hoc practices he observed, and that work appears to have ceased sometime in 2006. The Debian wiki page on the topic, though no doubt useful to some extent, seems more a collection of tips than an attempt at a policy. Is there a silent Debian Python policy drafter out there who would like to step forward? Or is this work now moribund? -- \ “The greater the artist, the greater the doubt; perfect | `\ confidence is granted to the less talented as a consolation | _o__) prize.” —Robert Hughes | Ben Finney pgpm1ff8b8vjj.pgp Description: PGP signature
Re: Work on a current Debian Python policy (was: Lintian warnings for Python packaging?)
On Mon, Nov 2, 2009 at 2:27 PM, Scott Kitterman deb...@kitterman.com wrote: I'm not aware of any ongoing work. I would be willing to help work on such a thing, but we currently lack a good mechanism for developing/approving such a policy. With clear policy and precise goal you won't need approving mechanism to see if they work for defined set of cases or not. While everybody want policy just to know how to do thing properly, there are in fact very few people who really understand how complicated is the task of maintaining python code, modules and applications. When there is precise goal, next action is to collect scenarios for the whole install/update/remove lifecycle of Python code in Debian. Only after this step is complete it is possible to start drafting self-explanatory architecture that will be capable to support all these scenarios. There is no need in mechanism for developing a policy - in wiki everybody can start contributing immediately with a full history of changes. There can be a sprint though to force the progress and keep work focused. To make it easier to contribute scenarios a template can come handy. I've edited http://wiki.debian.org/DebianPython to be concise introduction into the problems with Python code packaging, summarized issues with the current policy, but still can't provide vision for a new policy. That's why I'd like to see http://wiki.debian.org/DebianPython/Tutorial with step-by-step instructions and explanations of the reasons why things should be done in some particular way, what problems arise if they won't done as requested, and how it makes maintenance easier. There can be a series of tutorials starting with most basic packaging scenario (one module) and gradually move to most complicated (application with several C-modules installed in virtualenv). There is a difference in Scenario and Tutorial in that Tutorial is based on some policy draft while Scenario concentrates on a very-very source of the problem. I.e. scenario is As a user, I want some stable version of that Python module to be present for my scripts in my Debian installation or As an admin, I want to install Trac in isolated environment and upgrade it separately as security fixes are coming out. -- anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Work on a current Debian Python policy (was: Lintian warnings for Python packaging?)
On Mon, 2 Nov 2009 16:50:00 +0300 anatoly techtonik techto...@gmail.com wrote: On Mon, Nov 2, 2009 at 2:27 PM, Scott Kitterman deb...@kitterman.com wrote: I'm not aware of any ongoing work. I would be willing to help work on such a thing, but we currently lack a good mechanism for developing/approving such a policy. With clear policy and precise goal you won't need approving mechanism to see if they work for defined set of cases or not. ... Yes and we have neither right now. Writing stuff on a wiki won't change that. Until we have a legitimate Python policy, all we have to base decisions on is running code. All the code doesn't agree. Scott K P.S. I am subscribed to the list, so no need to cc me. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Questions about the Debian Python Policy
On Tue, 2005-10-25 at 08:40, Josselin Mouette wrote: Le lundi 24 octobre 2005 à 11:30 -0400, James A. Treacy a écrit : Thanks for the replies to my questions. I hope that a way to ensure automatic recompiling of python modules is implemented sometime in the future. If you want to automate the process on the packaging side, using dh_python will do all the work for you; you will only need a rebuild when the major python version changes. Support for rebuilding these modules automatically without rebuilding the package has been underway for quite some time, but still isn't usable. Do you mean; Rebuild = new source package upload + new generated binary packages + distribute to mirrors + download for install on systems? rebuild these modules automatically without rebuilding the package = only recompile *.py's installed on systems? major python version changes = python (2.3) upgrades to python (2.4)? I still don't see how anything is in place to recompile py's reliably when the default python upgrades. For example; package python-foo has Depends: python (=2.1), puts private pure python modules in /usr/share/lib/python-foo, and compiles them with #!/usr/bin/python. How will these *.py files be re-compiled when python (2.3) is upgraded to python (2.4)? -- Donovan Baarda [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Questions about the Debian Python Policy
Le mardi 25 octobre 2005 à 12:24 +0100, Donovan Baarda a écrit : If you want to automate the process on the packaging side, using dh_python will do all the work for you; you will only need a rebuild when the major python version changes. Support for rebuilding these modules automatically without rebuilding the package has been underway for quite some time, but still isn't usable. Do you mean; Rebuild = new source package upload + new generated binary packages + distribute to mirrors + download for install on systems? rebuild these modules automatically without rebuilding the package = only recompile *.py's installed on systems? major python version changes = python (2.3) upgrades to python (2.4)? Yes. I still don't see how anything is in place to recompile py's reliably when the default python upgrades. That's why I'm saying it is underway. It's not currently possible by any means. Regards, -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: Questions about the Debian Python Policy
On Sat, 2005-10-22 at 22:27, James A. Treacy wrote: I have some questions relating to python packages and the python policy. I maintain a pure python program (gramps) that relies heavily on other python packages: python-gnome2, python-glade2, python-reportlab and python-gnome2-extras. Section 3.1 of the python policy states that programs which can use any version of python which depend on python module Foo should depend on python-foo, not pythonX.Y-foo. This can be problematic for the following reason. Actually, they should have Depends: python (=X.Y), python (X.Y+1) where X.Y is the current default version of python. Let's use gramps(*) as an example and that the default python switches to 2.4. A user upgrades python (leaving 2.3 on the system), gramps and python-glade2 to python 2.4 versions but does not ugrade python-gnome2 (this works since python 2.3 is still installed). All the dependencies will be met but gramps will not work as it will not find all the required (2.4 based) dependencies. This should not work because the old version of python-gnome2 should have Depends: python (=2.3), python (2.4). This means it cannot be installed alongside python (2.4). When you install python (2.4) you will be forced to upgrade python-gnome2 to use the new version that has Depends: python (=2.4), python (2.5). How do you propose avoiding this situation without having programs depend on pythonX.Y-foo packages explicitly? With the versioned dependency on python... Second question. Gramps installs its private modules in /usr/share/gramps instead of /usr/lib/site-python/gramps as specified in the policy. Is this ok? If not, why? It is OK, provided you address the following issues; 1) how does gramps applications find these private modules? 2) how do you ensure that these private modules are re-compiled when python (X.Y) upgrades to python (X.Y+1)? Third question. The examples for compiling python modules in the postinst use a specific version of python. Since gramps is compiled against the default verson of python, is it ok to just use PYTHON=python? Yes, but you need to make sure that a re-compile is triggered when python itself gets upgraded. The brute-force way, as described in the current policy, is to have Depends: python (=X.Y), python (X.Y+1), which will force you to release a new version of your package with new dependencies when python upgrades... installing a new version of the package will re-compile the py's. Using tight version constraints to force package upgrades just to trigger re-compiles is very ugly though. Sure, if you had binary extensions that needed to be re-built anyway, it is no extra work, but for a pure python package it feels wrong. The other alternative is to have the python package trigger the compiles for you when it is installed. Currently, the python package does no postinst compiles at all. The pythonX.Y packages will only compile everything in /usr/lib/python2.3. So you can't do it. I've been advocating the brute force solution of having python's post-inst trigger the postinst scripts of every package that depends on python. This way packages that depend on python can re-compile their own *.py's when python is upgraded. So far, no-one has responded... Some packages (python-roman, pychecker, python-epydoc, apt-listchanges, python-docutils) have taken to putting version independant pure-python modules in /usr/lib/site-python. This is on every python versions path, so this makes the modules available to every python version. However, it has several problems; 1) the *.pyc's can only be compiled for one version of python. When you use a different version of python, the pyc's will be re-compiled. If the user has write access to /usr/lib/site-python, the old pyc's will be overwritten. 2) which version of python do you use? You should use the version of python that corresponds with your package's dependencies (usually python). 3) if you compile using /usr/bin/python, how do you recompile when python upgrades? Right now you can't. It seems all of the packages using /usr/lib/site-python have a different approach, and usually get it wrong in some way. For example, pychecker has Depends: python2.3 | python2.2 | python2.1 | python and it's postinst uses the first found in python python2.3 python2.4 python2.2 python2.1. Its dependencies and what it actually uses are different, and hence wrong. The package maintainer is at least aware of the issues, and has a big comment in his postinst about it. python-epydoc is similar to pychecker, but has Depends: python2.3 | python2.2-xmlbase | python2.1-xmlbase, so it relies on indirect dependencies for python2.2 and python2.1. However, it too will attempt to compile with the first found in python python2.3 python2.4 python2.2 python2.1. python-roman has Depends: python (= 2.1), but its postinst is hardcoded to use python2.3. This package will break if you try to install it without python2.3 installed, but
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 --
Re: Debian Python policy Upgrade Path (draft/proposal) [0.3.3]
On Tue, Oct 23, 2001 at 01:33:29AM +0200, Matthias Klose wrote: 3.1. Version Independant Programs - Programs that can run with any version of Python must start with `#!/usr/bin/env python'. They must also specify a dependency on `python-base'. Using #!/usr/bin/python also seems entirely legitimate, and a few /usr/bin scripts on my system do that. They should also Depend: on python-foo for any modules they require, presumably. They may also want to Depends: python-base (= X.Y) if they use some features that were only introduced in python X.Y. 3.2. Version Dependant Programs --- Programs which require a specific version of Python must start with `#!/usr/bin/env pythonX.Y'. They must also specify a dependency on `pythonX.Y'. Likewise /usr/bin/pythonX.Y doesn't seem unreasonable. 4. Programs Embedding Python Programs which embed a Python interpreter must declare a `Build-Depends' on `pythonX.Y-dev'. Any particular reason why they should B-D on pythonX.Y-dev instead of python-dev? If they break in the future, they'll just stop building correctly and obviously need source changes anyway, no? Much like the various problems we have when gcc stops supporting some random way of coding that used to work. I presume the Depends: for this are already covered in the module packaging rules. 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: Debian Python policy Upgrade Path (draft/proposal) [0.3.3]
Matthias Klose wrote: - Recommend /usr/bin/env python over /usr/bin/python Again I must express my opposition to this idea. Using /usr/bin/env totally breaks dependencies. There's no way that I'm going to let Debian policy dictate what I can have in my path. Neil
Re: Debian Python policy Upgrade Path (draft/proposal)
On Sun, Oct 21, 2001 at 10:27:54AM +1300, Carey Evans wrote: Matthias Klose [EMAIL PROTECTED] writes: [...] exactly. But you see that these packages will break when you try to upgrade. We can't make 2.1 the default right now, because we will _silently_ break packages. Before python can point to python2.1, we will have to fix all packages which depend on python-base, to depend on python-base ( 1.6). But if we get Python 2.1 into Debian 3.0, people will be upgrading from the old Python 1.5 packages in Debian 2.2 directly to the new packages, and unless they use apt-get dist-upgrade to upgrade to the newest versions of everything, packages will still be broken. For that matter, just getting everyone using testing to transition over to the new versions properly will be nearly impossible unless there are appropriate conflicts and dependencies to make sure that only working combinations of packages can be installed. Good point... I'd forgotten about that. This means we might as well go strait to python2.1 as the default, but make sure that the python2.1-xxx packages have versioned conflicts with all the packages that depend on just python or python-base and install into /usr/lib/python1.5/. Perhaps the best way to do this is have python-base (2.1xxx) have all the conflicts, allowing the other packages to be relatively clean. -- -- ABO: finger [EMAIL PROTECTED] for more info, including pgp key --
Re: Debian Python policy Upgrade Path (draft/proposal)
Donovan Baarda [EMAIL PROTECTED] writes: Good point... I'd forgotten about that. This means we might as well go strait to python2.1 as the default, but make sure that the python2.1-xxx packages have versioned conflicts with all the packages that depend on just python or python-base and install into /usr/lib/python1.5/. Perhaps the best way to do this is have python-base (2.1xxx) have all the conflicts, allowing the other packages to be relatively clean. Another possibility is for python-base to go away, and for a new package that conflicts with it, and has a different name, to take its place. In stable, it seems that only bg5ps, grmonitor, pythondoc and sketch depend on python, compared to 59 which depend on python-base, so this would make the Conflicts field just a little bit shorter. (Actually 60, but gimp-python also depends on python-base ( 1.6.0)). Packages that depend on python: grep-dctrl -FDepends -e 'python([ ,]|$)' Packages Packages that depend on python-base: grep-dctrl -FDepends python-base Packages It seems things have gotten worse... I count 22 packages in unstable that depend on python, and around 101 that depend on python-base only once. -- Carey Evans http://home.clear.net.nz/pages/c.evans/ Ha ha! Puny receptacle!
Re: Debian Python policy Upgrade Path (draft/proposal)
Carey Evans writes: Matthias Klose [EMAIL PROTECTED] writes: [...] 2.4. Dependencies - Packaged modules must depend on `python-base ( X.Y)' and `python-base ( X2.Y2)'. (= X.Y), right? Shouldn't this explain just what X2.Y2 is? I assume it's actually X.Y+1, i.e. =1.5 and 1.6, =2.1 and 2.2, =2.9 and 2.10, etc. Thanks. Updated in 0.3.2: http://ftp-master.debian.org/~doko/python/
Re: Debian Python policy Upgrade Path (draft/proposal)
Donovan Baarda writes: On Sun, Oct 21, 2001 at 10:27:54AM +1300, Carey Evans wrote: Matthias Klose [EMAIL PROTECTED] writes: [...] exactly. But you see that these packages will break when you try to upgrade. We can't make 2.1 the default right now, because we will _silently_ break packages. Before python can point to python2.1, we will have to fix all packages which depend on python-base, to depend on python-base ( 1.6). But if we get Python 2.1 into Debian 3.0, people will be upgrading from the old Python 1.5 packages in Debian 2.2 directly to the new packages, and unless they use apt-get dist-upgrade to upgrade to the newest versions of everything, packages will still be broken. The only reason not to go to 2.1 directly is not breaking the packages in unstable.
Re: Debian Python policy Upgrade Path (draft/proposal)
Carey Evans writes: Donovan Baarda [EMAIL PROTECTED] writes: Good point... I'd forgotten about that. This means we might as well go strait to python2.1 as the default, but make sure that the python2.1-xxx packages have versioned conflicts with all the packages that depend on just python or python-base and install into /usr/lib/python1.5/. Perhaps the best way to do this is have python-base (2.1xxx) have all the conflicts, allowing the other packages to be relatively clean. It is probably better. Currently a package maintainer cannot make a final version of his package, depending on python-base, if he wants to use python2.1. Another possibility is for python-base to go away, and for a new package that conflicts with it, and has a different name, to take its place. basically that is Neil's proposal of a python-api package. In stable, it seems that only bg5ps, grmonitor, pythondoc and sketch depend on python, compared to 59 which depend on python-base, so this would make the Conflicts field just a little bit shorter. It seems things have gotten worse... I count 22 packages in unstable that depend on python, and around 101 that depend on python-base only once. well, I count 121 ... we could get this down to 63 for the woody release. So if we do this, we should inform the package maintainers ... - either depend on python-base (= 2.1), python-base ( 2.2) - or depend directly on python2.1-base (python2 is going to be dropped), or if not possible on python1.5-base, and call the versioned interpreter explicitely (python1.5, python2.1). appended is a Conflicts: line for a new python-base (2.1) and a list of maintainers/packages which are affected. python-base (2.1) Conflicts: bg5ps (= 1.3.0-1), cfv (= 1.9-2), cooledit (= 3.17.1-2.2), cplay (= 1.43-1), dcoppython (= 2.2.1-1.2), doc-central (= 1.3), dput (= 0.8.9.1), entity-python (= 0.7.2-1), fetchmailconf (= 5.9.3-1), forg (= 0.03-1), fsh (= 1.1), gadfly (= 1.0-6), garchiver (= 0.5-1), getmail (= 2.1.3-1), gif2png (= 2.4.0-2), glimmer (= 1.0.8-4), gnats2w (= 0.15.2), gnumeric (= 0.72-0.1), gramps (= 0.5.1-1), grc (= 1.0.1), grmonitor (= 0.81-2), guppi (= 0.35.5-4), htmlgen (= 2.2.2-4), iceme (= 1.0.0-2), icepref (= 1.1-7), ilu-base (= 2.0.0.91-3), imgsizer (= 2.1-1), ipcheck (= 0.132-1), jack (= 2.99.6-2), jaxml (= 2.22-1), junior-programming (= 1.1), kdelibs3 (= 4:2.2.1-12), kdesdk-scripts (= 2.2.1-3), kivio (= 1:1.1.0-final-6), knewsticker-scripts (= 2.2.1-2), libguppi11 (= 0.35.5-4), libwxgtk2.2-python (= 2.2.6.1), lilypond (= 1.4.8-1), linbot (= 1.0.0-2), lincredits (= 0.2), luci (= 0.1.1-1.1), lyx (= 1.1.6fix3-2), lyx-cjk (= 1.1.6fix3-1), mailman (= 2.0.6-1), muttzilla (= 0.40-9), omniorb (= 1:3.0.4-2.1), plucker (= 1.1.13-1), plwm (= 2.3-1), pms (= 0.2.17-1), poxml (= 2.2.1-3), pybliographer (= 1.0.9-5), pyching (= 1.0.4-2), pycmail (= 0.1), pydb (= 1.01-2), pydf (= 0.9.5), pydict (= 0.2.5.1-1), pyftpd (= 0.7), pyg (= 0.9.4-7), pyrite-publisher (= 1.99.2-1), pysol (= 4.60-1), python-4suite (= 0.11.1-2), python-bobo (= 2.1.4-5), python-bobodtml (= 2.2.1-5), python-bobopos (= 2.1-4), python-cddb (= 1.3-3), python-distutils (= 1.0.2-1), python-extclass (= 1.2-4), python-gdk-imlib (= 0.6.8-8), python-gendoc (= 0.73-5), python-glade (= 0.6.8-8), python-gtk (= 0.6.8-8), python-gtkglarea (= 0.6.8-8), python-happydoc (= 1.5-1), python-id3 (= 1.0-1), python-imaging (= 1.1.2-3), python-kjbuckets (= 2.2-6), python-mxdatetime (= 1.3.0-5), python-mxstack (= 0.3.0-4), python-mxtexttools (= 1.1.1-3), python-mxtools (= 1.0.0-4), python-mysqldb (= 0.9.0-1), python-newt (= 0.50.17-7), python-numeric (= 17.1.2-6), python-numeric-tutorial (= 17.1.2-6), python-orbit (= 0.3.0-2), python-orbit-dev (= 0.3.0-2), python-pam (= 0.4.2-3), python-pcgi (= 1.999a5-2), python-pygresql (= 7.1.3-4), python-pyqt (= 2.5-1), python-reportlab (= 1.08-1), python-slang (= 0.2.0-1), python-soap (= 0.8-1), python-stats (= 0.5-1), python-unit (= 1.4.1-1), python-utmp (= 0.4), python-vtk (= 3.1.2-1), python-xlib (= 0.8-1), python-xml (= 0.6.6-2), python-xmlrpc (= 0.8.6-3), pythondoc (= 0.6-2), quantlib-python (= 0.2.0-1), reportbug (= 1.31), routeplanner (= 0.11), routeplanner-gnome (= 0.11), scanerrlog (= 2.00-1), scigraphica (= 0.7.1-5), scigraphica-gnome (= 0.7.1-5), sgmltools-lite (= 3.0.3.0.cvs.20010909-3), sip (= 2.5-2), snappea (= 3.0d3-8), subterfugue (= 0.2-1), sulfur (= 0.1.3), syslog-summary (= 1.10.1), twisted (= 0.10.2-1), viewcvs (= 0.7-3), woody (= 0.1.6-2), xanim-modules (= 2.80.1.12), xbel-utils (= 0.6.6-2), xracer-tools (= 0.96.9-10), zope-bytecodehacks (= 0.1.7-2) The package list sorted by maintainer: JP Sugarbroad taral at taral.net ['scanerrlog', 'jaxml'] Dr. Guenter Bechly gbechly at debian.org ['iceme'] Ron Lee ron at debian.org ['libwxgtk2.2-python'] Danie Roux droux at tuks.co.za ['garchiver'] Matthias Klose doko at debian.org ['python-numeric', 'python-numeric-tutorial', 'python-distutils']
Re: Debian Python policy Upgrade Path (draft/proposal)
Donovan Baarda writes: Good point... I'd forgotten about that. This means we might as well go strait to python2.1 as the default, but make sure that the python2.1-xxx packages have versioned conflicts with all the packages that depend on just python or python-base and install into /usr/lib/python1.5/. Perhaps the best way to do this is have python-base (2.1xxx) have all the conflicts, allowing the other packages to be relatively clean. I've made python packages defaulting to 2.1 (not in incoming) and have put them on ftp-master. deb http://ftp-master.debian.org/~doko/python ./ There is a second (currently empty) directory writable for Debian, which could serve as a place to collect NMUs for the new schema. deb http://ftp-master.debian.org/~doko/python-nmus ./ Comments are welcome.
Re: Debian Python policy Upgrade Path (draft/proposal)
Matthias Klose [EMAIL PROTECTED] writes: [...] exactly. But you see that these packages will break when you try to upgrade. We can't make 2.1 the default right now, because we will _silently_ break packages. Before python can point to python2.1, we will have to fix all packages which depend on python-base, to depend on python-base ( 1.6). But if we get Python 2.1 into Debian 3.0, people will be upgrading from the old Python 1.5 packages in Debian 2.2 directly to the new packages, and unless they use apt-get dist-upgrade to upgrade to the newest versions of everything, packages will still be broken. For that matter, just getting everyone using testing to transition over to the new versions properly will be nearly impossible unless there are appropriate conflicts and dependencies to make sure that only working combinations of packages can be installed. -- Carey Evans http://home.clear.net.nz/pages/c.evans/ Ha ha! Puny receptacle!
Re: Debian Python policy Upgrade Path (draft/proposal)
Matthias Klose [EMAIL PROTECTED] writes: [...] 2.4. Dependencies - Packaged modules must depend on `python-base ( X.Y)' and `python-base ( X2.Y2)'. (= X.Y), right? Shouldn't this explain just what X2.Y2 is? I assume it's actually X.Y+1, i.e. =1.5 and 1.6, =2.1 and 2.2, =2.9 and 2.10, etc. -- Carey Evans http://home.clear.net.nz/pages/c.evans/ Ha ha! Puny receptacle!
Debian Python policy Upgrade Path (draft/proposal)
[Please CC me on replies] I made a new version of the Debian Python Policy, based on Neil's Python Policy (0.1), the new Python packages in unstable and Donovan's comments on the upgrade procedure. It's appended and available from http://ftp-master.debian.org/~doko/ (including the sgml source). Comments (and patches against the sgml source) are appreciated. Matthias PS: Install the build-dependencies of debian-policy and run nsgmls -gues python-policy.sgml debiandoc2text python-policy.sgml to check and build the sgml file. Debian Python Policy Neil Schemenauer [EMAIL PROTECTED] Matthias Klose [EMAIL PROTECTED] version 0.3 --- Abstract This document describes the packaging of Python within the Debian GNU/Linux distribution and the policy requirements for packaged Python programs and modules. Copyright Notice Copyright (C) 1999, 2001 Software in the Public Interest This manual is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. A copy of the GNU General Public License is available as `/usr/share/common-licences/GPL' in the Debian GNU/Linux distribution or on the World Wide Web at The GNU Public Licence (http://www.gnu.org/copyleft/gpl.html). You can also obtain it by writing to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. --- Contents 1.Python Packaging 1.1. Stable and Legacy Versions 1.2. Base Package 1.3. Module Path 1.4. Documentation 2.Packaged Modules 2.1. Support Only The Default Version 2.2. Support a Particular Version(s) 2.3. Support All/Most Versions (Including Default) 2.4. Dependencies 2.5. Module Package Names 3.Python Programs 3.1. Version Independant Programs 3.2. Version Dependant Programs 4.Programs Embedding Python 4.1. Building Embedded Programs 4.2. Embedded Python Dependencies A.Upgrade Procedure --- 1. Python Packaging --- 1.1. Stable and Legacy Versions --- At any given time, the package `python-base' should represent the current stable upstream version of Python. XXX: Should we have an exception for the case, when a new upstream version is released during a Debian freeze? Only one package may contain the `/usr/bin/python' binary and that package must either be `python' or a dependency of that package. The `python' package must provide `pythonX.Y'; where X and Y represent the major and minor versions of the Python, respectively. There can be any number of legacy Python packages available. These must be named `python-X.Y' and include the file `/usr/bin/pythonX.Y'. 1.2. Base Package - In order to provide a minimal installation of Python for use by applications without requiring the whole of Perl to be installed, the `python-base' package contains the binary and a basic set of modules. 1.3. Module Path Python searches three different locations for modules. The module search path for Debian has been ordered to include these locations at the beginning of the path in the following order: /usr/local/lib/site-python /usr/local/lib/pythonX.Y/site-packages /usr/lib/pythonX.Y/site-packages 1.4. Documentation -- Python documentation is split out in separate packages `pythonX.Y-doc'. The package `python-doc' depends on the `pythonX.Y-doc' (the documentation of the current stable upstream version of Python. TODO: Policy for documentation of third party packages. --- 2. Packaged Modules --- There is more than one way to package a Python module: 1. Support only the default version. 2. Support a particular version, or some but not all versions
Re: Debian Python policy Upgrade Path (draft/proposal)
Matthias Klose wrote: At any given time, the package `python-base' should represent the current stable upstream version of Python. XXX: Should we have an exception for the case, when a new upstream version is released during a Debian freeze? It should probably be reworded so that it means the latest version we are able to get into the release. Only one package may contain the `/usr/bin/python' binary and that package must either be `python' or a dependency of that package. If you call the main package python-base then there is no python package. There can be any number of legacy Python packages available. These must be named `python-X.Y' and include the file `/usr/bin/pythonX.Y'. Here you have python-X.Y and elsewhere you have pythonX.Y. 1.2. Base Package - In order to provide a minimal installation of Python for use by applications without requiring the whole of Perl to be installed, the `python-base' package contains the binary and a basic set of modules. Perl? Why the -base? There is not a stripped down version of Python and a full version. Calling the package python is clearer, IMHO. Python searches three different locations for modules. The module search path for Debian has been ordered to include these locations at the beginning of the path in the following order: /usr/local/lib/site-python /usr/local/lib/pythonX.Y/site-packages /usr/lib/pythonX.Y/site-packages That should be: /usr/local/lib/pythonX.Y/site-packages /usr/local/lib/site-python /usr/lib/pythonX.Y/site-packages 3. Support all/most versions of python, including the default. Works only for architecture independant python modules. NOT YET SUPPORTED!!! I assume you are refering to scheme where modules would get installed into the search path of multiple Python interpreters. I'm not sure that's a good idea. 2. You have version independant Python scripts/programs. Create a single package that depends on `python-base'. Any name can be used, but `python-module' is recommended for a library. It should install modules somewhere inside `/usr/lib/python/' and use `#!/usr/bin/python' for programs. The `postinst' script should create symlinks in all `/usr/lib/pythonX.Y/' directories that point to its `/usr/lib/python/' files and compile them. If we going to do this, it's stupid for each package's pre/post scripts to do the work. I had implemented scripts so that packages could do: #!/bin/sh # postinst script PACKAGE=`basename $0 .postinst` /usr/lib/python/install-package $PACKAGE #!/bin/sh # prerm script PACKAGE=`basename $0 .prerm` /usr/lib/python/remove-package $PACKAGE Much cleaner and harder to screw up, IMO. 4.1. Building Embedded Programs --- Programs which embed a Python interpreter must declare a `Build-Depends' on `pythonX.Y-dev'. Extension modules should do this as well. A. Upgrade Procedure This section describe the procedure for the upgrade from the current `python-XXX (1.5)' packages to the `python1.5-XXX' packages, the removal of the `python2-XXX' packages and the upgrade to the recent `python2.1-XXX' upstream packages: 1. File bugs against any packages that do not meet the above alternatives for packages. I have almost all the packages fixed already (for my proposed policy, but it would be easy to change for your proposed policy). I was going to email the maintainers diffs. I'm about ready to give up trying to improve the Debian/Python situation. I assumed the Python maintainers were busy and that's why they didn't respond to any of my posts. Now, new packages have been installed into woody. Hmm. Neil
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: Debian Python policy.
Donovan Baarda [EMAIL PROTECTED] writes: [...] IMHO, the best solution given what you have described above is to make each new release of python as a python-X.Y package that installs /usr/bin/pythonX.Y, and have another small python package which depends on the latest python-X.Y and installs a /usr/bin/python link to /usr/bin/pythonX.Y. [...] I'm sorry for bringing this all up now, when it sounds like the policy and packages are basicly done... I was late into this and thought I'd throw in my 2c. You said that very well. Pretty much exactly what I have been thinking. Better late than never, but at the end of the day I suppose the maintainer, of python (and perhaps all the packages which depend on it, should decide, because they are doing the work, and I'm, not!
Re: Debian Python Policy [draft]
Carey Evans wrote: In my original example, spam embeds libpython2.1.so. It would make sense for this to mean it depends on python-api-2.1, though this isn't what the current shlibs file says. Only python can provide python-api-*. Neil
Re: Debian Python Policy [draft]
On Tue, Oct 02, 2001 at 06:53:39AM -0700, Neil Schemenauer wrote: Carey Evans wrote: In my original example, spam embeds libpython2.1.so. It would make sense for this to mean it depends on python-api-2.1, though this isn't what the current shlibs file says. Only python can provide python-api-*. Why? Could you better explain your reasoning here? On the face of it, it certainly seems that python-1.5 ought to be able to provide python-api-1.5. Jim Penny Neil -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Python Policy [draft]
Quoting Neil Schemenauer [EMAIL PROTECTED]: Jim Penny wrote: [...] The python is a small package to create a link from /usr/bin/python2.2 to /usr/bin/python. python-eggs is a dummy package for dependencies (similar to what is done for GCC). When we upgrade Python to 2.2 we have: /- python --- python-2.2 spam -- \--- python-eggs --- python-eggs-2.1 --- python-2.1 The dependencies are still broken. We could have: /\ spam -- python-2.1 \ python-eggs-2.1 --/ That makes spam dependent on the version of Python installed. Perhaps I'm missing some detail of Donovan's plan. The trick is the wrapper packages python-eggs version dependancy tied to the python wrapper package (look familiar?). The python-eggs package is used to pull in the latest python-eggs version package for the latest python, so it is tied to a particular version of the python wrapper package. /-- python (2.1) \ spam -- /\ \ (=2.1,2.2) python-2.1 \ / / \-- python-eggs /-- python-2.1-eggs --/ when we upgrade to python 2.2 /- python (2.2)- python-2.2 spam -- \ (=2.1,2.2) \ / \-- python-eggs /--- python-eggs-2.1 python-2.1 spam is broken because python-eggs is broken, but the dependancy system tells us it is broken because the python-eggs wrapper depends on a particular version of python that has been upgraded. The thing to remember is spam depends on the latest python and python-eggs. When python has been upgraded and python-eggs has not, the latest python + eggs combo is broken. There is nothing we can do about this... python (2.2) needs python-2.2-eggs for python + eggs to work. So we upgrade python-eggs; /-- python (2.2)-\ spam -- /\ \ (=2.2,2.3) python-2.2 \ / / \-- python-eggs /--- python-2.2-eggs -/ python-2.1-eggs --- python-2.1 Now everything is working again. We have upgraded python and python-eggs, and created python-2.2 and python-2.2-eggs. Note that at no stage did python-2.1 and and python-2.1-eggs break, so any packages that depended directly on them (ie, tied to the particular 2.1 version packages) never broke. The latest version of python + eggs briefly broke as the packages were upgraded. This clearly shows the benefits and drawbacks of versioned vs unversioned dependancies. spam could have a versioned dependancy against python-2.1 and it would never break as python-2.2 was introduced (provided python-2.1 packages continued to exist), however, it would have to be upgraded every time python upgraded to use the latest python. By not depending on a particular version of python, it doesn't need to be upgraded to use the latest python, but requires that the latest python + eggs combo is not broken. In my above diagrams the (=2.1,2.2) dependancy could be replaced with a python-api-2.1 provided by python (as suggested by Neil), but I think this actually introduces confusion rather than convenience. The problem is that it doesn't really represent a particular version of the api, just a particular version range of the latest python package. Note that my proposal actually has a lot in common with Neil's. We are both using (=2.1,2.2) dependancies to ensure the latest python + modules breaks when not all of them are of the same version, though in his case he has introduced the confusing python-api as a shorthand for this. Perhaps using python-base-2.1 or python-latest-2.1 would be less confusing, but I still think the version range is clearer. The only real difference is I'm proposing the latest packages be small wrappers around python-2.1 versioned packages. This means old versioned packages get created as you go, rather than after python upgrades, and they don't break as python upgrades. It also allows other packages to choose whether they depend on python, or python-2.1, even when python 2.1 is the latest version. -- ABO: finger [EMAIL PROTECTED] for more information.
Re: Debian Python Policy [draft]
Donovan Baarda wrote: In my above diagrams the (=2.1,2.2) dependancy could be replaced with a python-api-2.1 provided by python (as suggested by Neil), but I think this actually introduces confusion rather than convenience. The problem is that it doesn't really represent a particular version of the api, just a particular version range of the latest python package. It does represent the version of the API (for bytecode and the extension module binary interface). I suppose I am abusing it in the sense that only the python can provide it. If we go with your plan we drop -api bit and use python-X.Y instead. Neil
Re: Debian Python policy.
Quoting Neil Schemenauer [EMAIL PROTECTED]: Donovan Baarda wrote: Packages like extension modules _are_ tied to a particular version and hence should be in a python-X.Y-foo package that installs into /usr/lib/pythonX.Y. There would also be an empty package python-foo that simply depends on the latest python-X.Y-foo and python packages. I known this can be made to work. I think it's ugly and not worth the effort however. Perhaps we need to have a vote. Before I stir you guys into voting, perhaps I should clarify my postition. I don't (currently) mantain any python packages. I am an end user of python packages. I proposed the above because it is a way that Python packages could be smoothly and gradually upgraded when Python upgrades. I am concerned that the policy you are proposing will effectively break Python untill _all_ Python packages are upgraded. Things like Zope that cannot be upgraded as rapidly as the rest of Python will be broken until they are upgraded to use additional python-X.Y packages produced especially to support them. However, as I said, I am not a Python packager. Dispite the fact that I believe the above will reduce your workload in the long term, you guys are are the ones making the packages, and he who does it, gets to decide how it gets done :-) -- ABO: finger [EMAIL PROTECTED] for more information.
Re: Debian Python Policy [draft]
Neil Schemenauer [EMAIL PROTECTED] writes: spam should depend on python not python-2.1. In my original example, spam embeds libpython2.1.so. It would make sense for this to mean it depends on python-api-2.1, though this isn't what the current shlibs file says. -- Carey Evans http://home.clear.net.nz/pages/c.evans/ You think you know... what's to come... what you are.
Re: Debian Python Policy [draft]
On Sat, Sep 29, 2001 at 11:10:43PM -0700, Neil Schemenauer wrote: Carey Evans wrote: By way of example, suppose I have a package spam that embeds Python 2.1, and therefore depends on python-2.1. spam also uses the eggs module, and therefore depends on python-eggs, which depends on python-2.1 itself. Now Python 2.2 is released, and eggs is recompiled for it. The spam maintainer is on holiday, so it doesn't get recompiled for a while. If I then install lumberjack, which depends on python-2.2 and on eggs, apt will upgrade python and eggs to satisfy the dependencies, and hopefully install python-2.1 to keep spam happy. Still with me? All the dependencies are satisfied, but spam doesn't work any more - the eggs module has disappeared out from under it. Excellent point. I've updated the policy document to prevent this. The python package should provide python-api-X.Y. Module packages should depend on python-api-X.Y. If someone packages an older version of Python they should call it python-X.Y. Packaged modules for that Python should depend on python-X.Y. Older versions of Python should never provide python-api-X.Y. This fixes the dependancies, but requires new packages for old versions. Every new version of python will cause cascading updates of everything... updates of existing packages for the new python, and _new_ packages for the old version. Before all these packages are updated/created, everything is busted... even the new old python-X.Y is busted untill all the new python-X.Y-foo packages are created. Your only option is don't apt-update anything untill all the packages are done. Actually, the case of spam and eggs demonstrates how this busts things. No-one with spam installed will be able to install any of the new python packages untill spam is updated. Your only option is to remove spam if you want any new python packages. Installing a python-X.Y package won't fix it, since it doesn't provide python-api-X.Y. -- -- ABO: finger [EMAIL PROTECTED] for more info, including pgp key --
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
Debian Python policy.
G'day debian-python, Just read the DWN, saw mention of the Python policy, read it, and subscribed to this list to throw in some comments. I note that the policy was posted some time ago, so these comments might be too late. First off, you need to clarify what you are attempting to achieve. There are three possibile aims as I see it; 1) single official version of Python in archive/distro. 2) multiple alternative versions of Python in archive/distro, only one installed at a time. 3) multiple alternatives versions of Python installed at a time. Option 1 means every time Python upgrades, all packages dependant on that version of Python are broken and have to be upgraded, with old versions removed from the distro. Option 2 means every time Python upgrades, new versions of all version dependant python packages are added to the archive/distro at the mantainers lesure. Different versions of packages do not need to co-exist and must conflict with each other. Option 3 is similar to option 2, but different versions must be able to co- exist and shouldn't conflict with each other. Mechanisms need to be in place to ensure the correct version is used as needed. Why would you want multiple versions available/installed? One reason is new releases that are not backwards compatible, requiring old versions to run old software. Another reason is new versions being experimental, so you'd rather default to the old version but experiment with the new one. Your policy seems to be aiming for Option 3... the hardest, but is that really what we want? Option 2 looks viable to me, and is easier to achieve. Option 3 is highly suggestive of using the alternatives mechanism, which your policy doesn't mention. The policy says there should be a single python package of the latest version. Only a single package can provide /usr/bin/python. This suggests that when python upgrades, the old python package needs to be re-released as python-X.Y, and a new python package released. This is ugly... better way is to always release Python-X.Y packages, and use some mechanism to select which one is python. This can be done by all python-X.Y packages providing python. The python-X.Y packages can then either all conflict with each other, or use alternatives to select which is /usr/bin/python. Note that if it is desireable to have a python package for some reason (apt-get funnies, version dependancies etc), then have the python-X.Y packages provide python-base, and have the python package depend on python-base. The policy says that modules should be named python-foo and depend on python- X.Y. This breaks Option 2 and option 3 because it only allows for a single version of python-foo, which will be tied to a particular version of python. In reality there are some modules that are tied to a particular version of python (compiled against them), and some that are forwards compatible with some base version (=1.5). It would be nice if both types of packages could be handled with a minimum of upgrading required. I suggest modules that depend on python-X.Y should be named python-X.Y-foo, allowing for multiple versions of version dependant modules. Other modules should be named python-foo and depend on python (=X.Y). The lack of versioned provides makes things a little tricky... it would be nice if python-X.Y could provide python (X.Y), so python-foo could depend on python (=X.Y) (though even this introduces new problems). Without versioned provides, the best we can do is have installing python version X.Y depend on python-X.Y (ie installing latest python always installs the latest python-X.Y). Note that the same trick would need to be done with python-X.Y-foo packages... have a python-foo version X.Y package that depends on python-X.Y-foo so that other packages can depend on python-foo (=X.Y). There are heaps of fine details to nut out. I've got some more thoughts on this, but this email is getting long enough, so I'll shut up now :-) -- ABO: finger [EMAIL PROTECTED] for more information.
