unsubscribe
Dr. Ole Nielsen | Software Engineer Urban Risk Research Group | E: [EMAIL PROTECTED] Geoscience Australia | P: +61 2 6249 9048 Canberra, Australia | F: +61 2 6249 9986
Re: Python policy update
Le jeu 21/08/2003 à 04:24, Donovan Baarda a écrit : --- 1.4 Module Path, a question; Do we really want /usr/local/ on the python path before /usr/lib/? This makes us vulnerable to busted local installs of python modules, in the same way that #!/usr/bin/env python makes us vulnerable to busted local installs of python. Interesting question. The problem is then how to deal with a user/admin wanting to use a specific version of a single module and puts it in /usr/local. --- 2.2.1 Support Only The Default Version, questions and typo on last paragraph I think Build-Depends: python-dev (= X.Y) should be Build-Depends: python-dev (=X.Y), python-dev (X.Y+1), or doesn't Build-Depends support that. In any case, =X.Y is not sufficient to nail it down. I happen not to agree for the build-depends. Having them set at python-dev (=X.Y) allows for lazy rebuilding at the next python transition. The = X.Y is here mostly for the autobuilders, as in fact the package could build with earlier python versions if it uses dh_python. --- 2.2.3 Support All/Most Versions (Including Default), regarding 2. Part 2. still includes the unsupported stuff about using /usr/lib/python/site-packages. There was some discussion about using /usr/lib/site-python for this instead... should this be updated? The two cases are different: /usr/lib/site-python is meant for the default python version, while /usr/lib/python/site-packages was meant for all python versions at a time. But maybe this should be completely removed or commented out as it is not likely to be supported in the near future. --- 3.1 Version Independent Programs, comments The last para about private modules should also apply against anything that goes in /usr/lib/site-python and is only true because currently there is no mechanism to re-compile version independent packages when python (X.Y) upgrades. The moment python (X.Y) (and perhaps pythonX.Y) is capable of identifying dependent packages and re-compiling them, then there is nothing stopping dependencies like python (=2.0), python (2.4). Well, do you think the wording makes it unclear it is also true for stuff in /usr/lib/site-python? Regards, -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: Python policy update
Le mer 20/08/2003 à 14:09, Josselin Mouette a écrit : In order to make it up to date, and to match current packaging practices, I have prepared a draft for a python policy update. It is available at: http://people.debian.org/~joss/python/ I have updated this draft using suggestions from first replies. I have also clarified the dependencies on python modules, I think it must be made really clear so that no breakage can occur. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: Python policy update
On Fri, 2003-08-22 at 08:02, Josselin Mouette wrote: Le mer 20/08/2003 à 14:09, Josselin Mouette a écrit : In order to make it up to date, and to match current packaging practices, I have prepared a draft for a python policy update. It is available at: http://people.debian.org/~joss/python/ I have updated this draft using suggestions from first replies. I have also clarified the dependencies on python modules, I think it must be made really clear so that no breakage can occur. Nice work... some other things I noticed; 1.2. Main package, last paragraph The line; Its version must be greater than X.Y and smaller than X.Y+1. confused me a bit...till I figured out what you meant. Perhaps something like the following would be clearer; The version of the 'python' package must be greater than or equal to X.Y and less than X.Y+1. It's pretty good. The only other minor nitpick is I think that 3.1. Version Independent Programs should be changed to 3.1. Programs Using the Default Python. Also para 3.2 should probably be renumbered to para 3.1.1 as it applies specifically to programs using the default python. -- Donovan Baarda [EMAIL PROTECTED] http://minkirri.apana.org.au/~abo/
Re: python 2.2 - python 2.3 transition
On Thu, Aug 21, 2003 at 01:37:10PM +1000, Anthony Towns wrote: On Thu, Aug 21, 2003 at 12:34:12PM +1000, Donovan Baarda wrote: On Wed, 2003-08-20 at 15:49, Anthony Towns wrote: On Tue, Aug 19, 2003 at 11:44:22PM -0400, Derrick 'dman' Hudson wrote: The negative effect for the users is that you can't upgrade python while wxgtk-python is installed so you can't try out the latest-and-greatest python in the meantime. This is the issue at hand. Sure you can: $ sudo apt-get install python2.3 The dependency stuff merely notes that upgrading python without also upgrading wxgtk-python may break stuff. actually, if the dependencies are right, you cannot upgrade to python (2.3) without also upgrading to wxgtk-python (2.3) or de-installing wxgtk-python (2.2). Sure you can. dpkg --force-depends -i python_*.deb will do it for you. If you want something bad enough, and don't mind breaking things, anything's possible. Please, don't turn Debian into Red Hat ;-) Regards: David Weinehall -- /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/
