Respectfully request to join the debian python team
My name is Perry, I wanted to request to join the debian python team. In a previous email, I shared that I have been using debian for a while now and at this point in time I want to contribute back to the project. One of my skills is writing scripts in python, and I want to utilize and build upon this skill in contributing back to debian. I have read, understand, and accept the debian python team policy. Salsa Login: username - bpm10 pw - Crazydiamond.246 -- *Perry Ryan Cruz Aganad*
Re: Respectfully request to join the debian python team
Hi Stefano, thanks for the advice, I'll definitely take a look into patching and orphaned packages. As far as mentoring how would I go about doing that? finding one that is. On Thu, Jan 21, 2021 at 12:15 PM Stefano Rivera wrote: > Hi PerRy (2021.01.21_07:39:50_+) > > I wanted to request to join the debian python team. In a previous email, > I > > shared that I have been using debian for a while now and at this point in > > time I want to contribute back to the project. One of my skills is > writing > > scripts in python, and I want to utilize and build upon this skill in > > contributing back to debian. > > Aside from a password reset, I'd recommend getting started by > contributing patches through the bug tracking system, or adopting some > orphaned packages, and getting some experience maintaining them. Ideally > finding some mentors to help you out, along the way. > > We don't generally give people who are brand new to contributing to the > project commit access to hundreds of packages. > > SR > > -- > Stefano Rivera > http://tumbleweed.org.za/ > +1 415 683 3272 > > -- *Perry Ryan Cruz Aganad*
Looking to help
Greetings everyone!, I have been using debian for a while now and I am a point where I want to help and start contributing to debian itself. I read the web page about contributing and I took away that I should just jump right in, and I specifically jumped here because I do know how write python scripts. I am new at this but I'm a quick learner so please let me know if I can help out in anyway, thanks!.
Re: Executable files part of library
Magnus Therning wrote: Interestingly enough distutils doesn't keep executable bits on libraries, and this causes lintian to complain: W: python-pyggy: script-not-executable ./usr/lib/python2.3/site-packages/pyggy/dfa.py N: N: This file starts with the #! sequence that marks interpreted scripts, N: but it is not executable. N: bug in lintian, it should not complain about interpreter library files in this way. I believe there is already a bug(s) on this. Ignore it.
Re: Dependencies on Python
> > none; both packages should depend on python|python2 > I am just waiting till python2 packages stabilise to upload > versions with correct dependencies. > But, of course, the correct way would be to have > virtual package python, provided by python1-base and python2-base > it is my understanding that a) not all 1.5 is compatible with 2.x b) not all licenses of 1.5 are compatible with 2.x until this is fixed, the maintainer should not add the python2 depends until he has personally tested it.
RE: 4Suite in Debian ?
On 28-Feb-2001 Jérôme Marant wrote: > > Hi, > > Would you think great to have 4Suite (http://www.4suite.org) in Debian ? > As 4DOM was included in Python-xml, we could simply remove it from 4Suite > add a dependency instead. > I looked into packaging it for narval. However, the version of xml it wants versus what is in Debian were conflicting at the time. I no longer have the time to work on this, so feel free.
RE: 4Suite available in Incoming
On 02-Apr-2001 Jérôme Marant wrote: > > Hi, > > I made 4Suite available for unstable, it is waiting in Incoming. > Sorry for those who were waiting it to come out earlier but it > took more time than I was expecting. > > There are 2 packages: python-4suite and python2-4suite, and both > can be installed on the system thanks to alternative mechanisms. > why does this need alternatives? It should go in /usr/ib/python1.5/site-packages and python2.x/site-packages.
Re: 4Suite available in Incoming
On 03-Apr-2001 Jérôme Marant wrote: > "Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> writes: > > >> why does this need alternatives? It should go in >> /usr/ib/python1.5/site-packages and python2.x/site-packages. > > Alternatives are used for /usr/bin scripts and manpages, not > for libraries. > Was not aware this was any more than a collection of python libs, sorry.
Re: Python 2.1 out
On 18-Apr-2001 Gregor Hoffleit wrote: > On Tue, Apr 17, 2001 at 03:33:45PM +0200, Vasko Miroslav wrote: >> as Python 2.1 is out, there is no need to keep Python2 and Python152 >> in Debian, I think. >> >> it looks like 2.1 has GPL-compatible license (it has, in fact, three >> licenses) > > Thanks for pointing out the changes in LICENSE. Since there wasn't any big > noise lately, I thought they had postponed any actions after 2.1. > last I checked it only helped derivatives of python, not python itself.
RE: Package name question - pyada or python-pyada?
> I have filed an ITP for pyAda which is an Ada wrapper to allow Python to be > embedded and extended with Ada. Since pyada contains no python code I was > going to name the package pyada instead of python-pyada, or am I wrong > about the usage of 'python-' in a package name. > pyAda is the well known name, I would use that.
Re: [Python-Dev] Status of Python in the Red Hat 7.1 beta
On 07-Feb-2001 Moshe Zadka wrote: > On Wed, 07 Feb 2001 02:39:11 -0500, Guido van Rossum <[EMAIL PROTECTED]> > wrote: >> The binaries should be called python1.5 and python2.0, and python >> should be a symlink to whatever is the default one. > > No they shouldn't. Joey Hess wrote to debian-python about the problems > such a scheme caused when Perl5.005 and Perl 5.6 tried to coexist. Guido, the problem lies in we have no default. The user may install only 2.x or 1.5. Scripts that handle the symlink can fail and then the user is left without a python. In the case where only one is installed, this is easy. however in a packaged system where any number of pythons could exist, problems arise. Now, the problem with perl was a bad one because the thing in charge of the symlink was itself a perl script.
Re: Debian Python Policy [draft]
> > We could perhaps differenciate python modules and bindings. > > For example, libxml bindings for Python would be libxml-python. > Also, python-gtk would become libgtk-python, python-gnome would become > libgnome-python > and so on. > > However, xml tools for python would stay python-xml. > sounds sane.
RE: Debian Python Policy [draft]
On 18-Sep-2001 Neil Schemenauer wrote: > Please comment. > > Neil it is /usr/share/common-licenses, not licences. Annoying thing there being two spellings of some common words.
Re: lintian and new python policy
On 29-Oct-2001 Tom Cato Amundsen wrote: > Has anyone started modifying lintian? If I remember correctly, > packages that generate lintian errors will be rejected... > anyone is me, the maint. (-: Although any pythoners among you willing to get dirty with perl are welcome to send patches. > 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? I have been waiting for the policy to finalize. lintian handles official policy only. The two depends thing is something I have to revisit. I was trying to keep people from doing "Depends: libc, libc (>> 2.1)" or more simply "foo, foo".
Re: Build-Depends-Indep
On 07-Nov-2001 Danie Roux wrote: > Policy states that you should Build-Depends on python2.1-dev. > > Can this also be Build-Depends-Indep? I have a "Architecture: all" > package. It's just 3 python files. No need for "Architecture: any" > of course it can. We usually say "Build-Depends" when we mean any form of Build time depends info.
Re: Python2.2 doesn't build on potato
On 15-Dec-2001 Carel Fellinger wrote: > Hi, > > Today I tried the new Python2.2c1 to find that it doesn't build on potato. > It works out of the box on my woody system, but fails on my potato setup:( > The latest 2.2 that does build under potato is 2.2.a4 > > It seems to have to do with changes in the ssl libs. > SSL has changed a lot since potato, you may end up backporting a libssl from woody.
Re: Suggestion of dh_purepython
On 10-Jan-2002 Bastian Kleineidam wrote: > Hi Python folks, > > I have put together a dh_purepython debhelper script to help > the installation of pure Python packages. > > Still missing: > > 1) All Python X.Y versions need to be preinstalled. What happens >when you install an new Python version? Hmm, we have to >register those pure python packages somehow and byte-compile >them if we install a new pythonX.Y package. > read all python* binaries from /usr/bin, loop through every one that has a version on the end, strip the version out and use it. for i in /usr/bin/python* do # if $i ends in a number # pyver = $i's version number # call /usr/lib/python$pyver/compileall.py done
Re: dummy packages and lintian
On 08-Feb-2002 Federico Di Gregorio wrote: > hi, > > hi have python-psycopg be a fake package that depends on the right > python-psycopg package (i provide psycopg packages for python 1.5, 2.1 > and 2.2.) lintian give me an error saying that the package should > contain at least the copyright file. given that the copyright is > available because the package *depends* on a real package, should i > include the copyright even in the dummy package, symlink the doc > directory or file an override to lintian? > the override will require adding a file to your package too. So I would go for either the symlink or simply ignoring the error.
Re: Bug#128531: tmda
>
> Any policy that forces me to compile .py{c,o} object files in my postinst is
> braindead. Then I also have to delete them in purge/postrm, and the
> packaging system knows nothing about them.
>
A program run by a user will never be able to write out the .py[co] files so
the files MUST be generated by the postinst which has root privs. Also we can
not expect the user to be running /usr mount rw except when a package is being
installed. So even if the user is logged in as root they will still be unable
to write the optimized files out.
What do you have against giving the user optimizations?
Re: Bug#128531: tmda
>> >> What do you have against giving the user optimizations? > > Absolutely nothing, but I don't see why this needs to be done outside of > the package management system. > I fail to see why these files need to be known by dpkg? Many python modules are forwards compatible, I also fail to see why supporting more than one version of python is a problem.
Re: Bug#128531: tmda
On 20-Feb-2002 dman wrote: > On Wed, Feb 20, 2002 at 07:57:52AM -0800, Sean 'Shaleh' Perry wrote: >| >> >| >> What do you have against giving the user optimizations? >| > >| > Absolutely nothing, but I don't see why this needs to be done outside of >| > the package management system. >| >| I fail to see why these files need to be known by dpkg? Many python modules >| are forwards compatible, > > The bytecode files are version-specific even if the source code isn't. which was my point. To have multiple version support the object files must be made at install time.
Re: Bug#128531: tmda
> > They should be known by dpkg because they're part of the package. It's > impossible to support more than just the currently installed versions anyway. > Once a new version of python is added, the package will still need to be > updated or at least reinstalled to compile the modules for the new version. > Adam, that is the whole point of compileall.
pointers to a good example?
I am considering packaging my first python lib. Anyone have a pointer to a good package to use as a template? It contains a setup.py script so I do not think it will be too difficult. Comments on any gotchas welcome. The package is pyro -- http://pyro.sf.net. I am once again looking at Narval as they approach a release. They have moved from xmlrpc to pyro for whatever reason. When I attempted to package Narval in December it was quite a mess. Not sure if I will have more luck this time.
Re: Please test new 4suite
> > I put it at: > > http://people.debian.org/~jerome/python-4suite > > The package is now compatible with python-xml. Please test it. If > you think that is is reliable enough, I'll upload it and will be > able to close #128604, at last. > > Thanks in advance. > > Cheers, > > PS: I'm not sure about this, but it seems that the old version of > the package must not be installed on the system in order to build > the new package. Could someone try to build it and confirm? > I have a nice, huge dual 1.7ghz 500MB RAM machine on loan currently. Will get in a few builds for you this weekend. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please test new 4suite
On 05-Apr-2002 Jérôme Marant wrote: > > Hi, > > I've just built a preversion of the 4suite 0.12a2 snapshot. > Building the package takes a huge amount of time (the whole > documentation is processed with 4xslt, which is known as one of the > slowest XSLT processors) and packaging becomes more and more painful > with no real fine tuning of intall directories and tons of lintian > warnings to fix. > > I put it at: > > http://people.debian.org/~jerome/python-4suite the source is 600 so we can not download it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please test new 4suite
On 06-Apr-2002 Jérôme Marant wrote: > "Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> writes: > >>> http://people.debian.org/~jerome/python-4suite >> >> the source is 600 so we can not download it. > > My apologies. It is strange that scp copied them all 644 except from > this one. Fixed now. > Will get a few compilations in for you tomorrow. I presume the package is named 11.99 to allow for the 12 upgrade? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please test new 4suite
> > PS: I'm not sure about this, but it seems that the old version of > the package must not be installed on the system in order to build > the new package. Could someone try to build it and confirm? > confirmed. It finds the old module in the path which does not have the same hierarchy as the new version does. So when it tries to build the docs it dies trying to load the rdf and other modules. 4suite is obviously updating the python search path to add its modules, the modules should be added at the front of the list and not the end where they seem to be added. The package will not build for me. It dies while trying to make the python2.2 version. Several tracebacks that I can not see they whiz by and then it ends with: DistExt/BuildDocs.py line 396 in doc_scripts app = getattr(module, script.identifier)() AttributeError: 'module' object has no attribute 'XsltCommandineApp' Total compilation time is around 10 minutes on this machine. Suggestions? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please test new 4suite
>> >> 4suite is obviously updating the python search path to add its modules, the >> modules should be added at the front of the list and not the end where they >> seem to be added. > > This really sucks. I don't have in mind any package that requires the > removal > of the old version in order to build. However, upstream said they don't > care. > we SHOULD be able to fix this ourselves, I just do not know enough about distutils yet to tackle it. > > It happened once on my system and I just removed the package directory, > then > unpacked it again (dpkg-cource -x package.dsc) and rebuild the package. > I cannot explain why this happens. > It looks like the building failure changed something. > I tried that to no avail. Any ideas? > PS: I hope they'll provide prerendered html documentation otherwise our > autobuilders will suffer. > the other choice is to render the html once and make a new tarball. Yes the orig.tar.gz will be slightly less pristine, but it will save the rest of Debian hours of time. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please test new 4suite
> > I have one more question: AJ wants to release Woody in May, so there are > not a lot > of weeks left. What can I do with 4suite since it is quite broken in Woody > ? > Should I release this pre0.12 or should I stick with 0.11.1 ? > damned if you do, damned if you don't. 0.12 uses a new API so anything using 4suite in woody will break most likely. I say stick with 0.11 and put 0.12 in unstable. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please test new 4suite
>> >> apt-cache showpkg doesn't show any reverse dependencies for 4suite, so >> an upload might be safe ... > > Well, some api changed. It might not be reasonnable ... > consider people using it as a depends for software not in Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Possible workaround [Re: Please test new 4suite]
On 07-Apr-2002 Jérôme Marant wrote: > > Hi, > > It seems that 4suite people ship a tarball > of prerendered 4suite docs. > I think I can release it sepearately. Since the conflicts > happen only when the docs are built, I can both avoid > to make the package conflict on the previous version > and avoid to render the documentation. > > Does this sound better? > definately. Although I am still confused about why I can not build the 4suite with python2.2, it works with 2.1. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python-jabber test pkg ready
>
> making python-jabber2.{1,2} would let it, but is it the correct way?
>
if you want to support multiple python versions, yes. You could also make a
python-jabber package which depended on the newest python version you support.
That way a user can just use python-jabber and let the upgrades move him
forward.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python-jabber test pkg ready
> > Q2: python-jabber uses socket.ssl (libssl), should I > put it in a section != main? python is in main. > ssl is fine in main now. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: python-gtk and python-gtk2 (and gnome packages), please comm
> > === > 3. > === > Quite messy, but... > Since python-gtk2 require python2.2 or later, we let python2.1-gtk > install as upstream does (in /usr/lib/python2.2/site-packages/) and > install python2.2-gtk in /usr/lib/python2.2/site-packages/gtk1.2/. And > python2.2-gtk2 can install as upstream does in > /usr/lib/python2.2/site-packages. > > This way maintainers of packages that depend on the old bindings can > stay with python2.1 without changing the packages, or add > sys.path.insert if they update the packages to python2.2. And programs > that use python2.2-gtk2 and python2.2-gnome2 will run without changes on > debian. > why is this so messy? You only compile for one python version and you match the upstream in either case. The existing software works perfectly without change in both cases. Seems like everyone wins here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: python-gtk and python-gtk2 (and gnome packages), please comm
>> >> why is this so messy? You only compile for one python version and you match >> the upstream in either case. The existing software works perfectly without >> change in both cases. Seems like everyone wins here. >> > > Ok, not messy, but the most "complicated", since programs that depend on > python2.1-gtk need no change, but if they depend on python2.2-gtk, they > need an sys.path.insert. Maybe this is the best. Thats why I would like > to hear peoples opinion. > it is not that harsh to simply limit python apps using gtk 1.2 to python version 2.1. If they want to move up to 2.2 (or higher) they have to port to gtk 2.0. that is my opinion anyway. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#148415: jack: should use #!/usr/bin/python
> > Not OK, since the locally-installed Python may not/will not have > access to jack's site-python files. Using /usr/bin/env python is IMHO > only acceptable if the package is self-contained or munges sys.path to > include any non-standard modules in the search path. > indeed. If you have python in /opt/python/ and env can find it, none of the Debian scripts will work because they do not know how to find their modules. When packaging something for Debian, it is usually best to assume they are using Debian's packages. If the user wants their own version of python, they can make a python package and install it instead of ours. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Emacs in build-depends of python2.1
> > Converting a hack to another hack with no strong reason nor fun is not > exactly what I dream of every night. > > So, I am not sure that such a conversion would be worth the time spent. > If despite all of this you still want to tackle on this task and have > some ELisp questions (I think it should be OK with Python ;-), feel > free to ask me, but don't count on me to do this. Sorry. > The problem is we now have a piece of a fairly common package using script(s) in a language few understand. So if you get hit by a bus someone WILL have to reverse engineer that script. This is the same reason I dislike build-essential requiring Haskell. It is a fine language but the number of people in Debian who speak it is probably about 20 or 30. In essential we have sh, sed and awk guaranteed. Just beyond that is perl and python. Then there is C(++). Once you move beyond these the chances of the typical developer being able to debug, help, or rewrite is small. elisp is even more specialized then just lisp. And yes it is annoying when you do 'apt-get --build python' to discover suddenly that emacs is going to be installed if for no other reasons than the build system just gained another 50+mb in size (some of us use chroots on smaller drives). I understand you not feeling the need is high to change now. But bear these thoughts in mind in the future. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Emacs in build-depends of python2.1
On 26-Jun-2002 Florent Rougon wrote: > "Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> wrote: > >> The problem is we now have a piece of a fairly common package using >> script(s) in a language few understand. So if you get hit by a bus >> someone WILL have to reverse engineer that script. This is the same > > Well, I guess you mean "py2texi.el's upstream maintainer" instead of > "you". Has someone had problems contacting him? Does his script often > break? The home page, <http://www.zamazal.org/software/python/py2texi/>, > is mentioned at the beginning of py2texi.el. > hmm, sorry, was going on other people's comments here. I was not aware you inherited this from the upstream. Please allow me to eat my foot (-: > > These are the implementation quirks. Now: > - is it the only .el file used in the whole Python build? > - are you sure the locally-and-not-installed python binary would be >able to use modules like re, StringIO, etc.? > - does someone actually use these info files, which are not supported >by upstream and may be incorrect: > > "The result code is ugly and need not contain complete information > from Python manuals. I apologize for my ignorance, especially > ignorance to python.sty" > >due to the difficult nature of such a conversion? I use the python info docs nearly every time I code in python and would miss them a lot. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Emacs in build-depends of python2.1
> BTW, if you're looking for a really nice and practical solution, you > should convince/help Python documentation team to switch to another > source format. LaTeX is really bad choice for such a documentation. > this sounds like a great idea, LaTeX is really not meants as a one to many format. Do you think there would be opposition to using say docbook? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Emacs in build-depends of python2.1
> >> Converting a hack to another hack with no strong reason nor fun is not >> exactly what I dream of every night. >> >> So, I am not sure that such a conversion would be worth the time spent. >> If despite all of this you still want to tackle on this task and have >> some ELisp questions (I think it should be OK with Python ;-), feel >> free to ask me, but don't count on me to do this. Sorry. > > somebody to volunteer for a pythonic conversion of the docs? > the real answer as was discussed would be to move the Python docs to a format designed for interchange (most likely docbook). texinfo simply is not meant for this. Coupling this work with a comprehensive list of undocumented modules, perhaps getting them documented along the way would really be a great idea. The question really boils down to whether the upstream want this to happen or not. Roughly 5 people and a month or two's work should cover it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Maintaining Python 1.5
On Tuesday 10 September 2002 15:09, Chris Lawrence wrote: > On Sep 10, Matthias Klose wrote: > > Moshe Zadka writes: > > > I was wondering if you mind passing Python 1.5 maintainership to me. > > > > I do not mind passing the maintainership, but I do mind keeping it in > > unstable. Debian is not a museum for old python versions. What hinders > > you to install the python1.5 packages from woody in unstable? apt > > tagging is your friend. > > Well, two problems I can see: > > 1. Woody will eventually go away to archive.debian.org land, not long >after sarge is released. > > 2. There are woody Python packages that want libdb1, which disappears >from libc6 in sid/sarge. > > I agree we shouldn't keep it around forever, but it seems like as long > as people are using python1.5 with post-woody we should keep it. > > > Chris Plus there are alreayy glibc changes in sid/sarge so people running woody are being forced to upgrade glibc or compile packages by hand. There is still a fair amount of software that has only been tested with 1.5 so it is not necessarily museum quality.
Re: Maintaining Python 1.5
On Wednesday 11 September 2002 15:00, Matthias Klose wrote: > Neil Schemenauer writes: > > Matthias Klose wrote: > > > Moshe Zadka writes: > > > > I was wondering if you mind passing Python 1.5 maintainership to me. > > > > > > I do not mind passing the maintainership, but I do mind keeping it in > > > unstable. > > > > I don't think it is up to individual Debian developers to decide what > > packages should be allowed in Debian. > > ??? Interisting. So I am allowed to package perl3, quichote-0.1 and > marlais 0.5? If you wanted to and could make sure it did not break anything, why not. I could definately see something like this making sense in a corporate setting. A Debian devel may not be allowed to upgrade some of their boxes and it would be easier to use foo X.Y on all platforms than deal with the compatibility. This is also why it makes sense to keep python1.5 around. As Moshe points out python1.5 is still the python most RH users get and it is way too easy to let a 2.x ism into your code. Hell on a python list this morning I was reminded that a solution I proposed only works in 2.2.1+.
