I'm the maintainer of the python-mode package.
Recently someone emailed me pointing out that it didn't work after they
upgraded to python2.3. The reason it is failing for 2.3 would be
because of the "b" in the current python version (2.3b1).
I could fix this by changing my dependency to "python22" instead of
specific version of "python". However, this got me thinking that I
don't like the way it is currently packaged, and I'd like to fix it.
This is how it is currently packaged:
* It depends on python 2.2 explicitly
Depends: emacsen, python (>= 2.2) | python-nox (>= 2.2), python (<<
2.3) | python-nox (<< 2.3))
* It has no source tarball of its own. It just copies python-mode.el
from the python package and installs it so that emacs will find it.
* The package version (4.6.18.2) is the version of python-mode.el
Now that we have python2.3, which includes an updated python-mode.el
(4.32), how should we handle the multiple versions of python? I can see
the following choices:
(1) upgrade python-mode package to 4.32 and include the python2.3
tarball as a source, just to pull out one file (python-mode.el)
(2) create different python-mode22 and python-mode23 packages that
depend on python22 and python23 respectively.
(3) Make python-mode a splitoff from the python package.
I think (1) is the best solution. It allows people still using
python2.2 to use the new improved python-mode (4.32)
I don't like (2). Why create new packages if you don't need to.
I'm not sure about (3), I think it has the same problems as (2) and it
would have to be done by the python maintainer.
So before I start implementing (1), I thought I'd run it by the mailing
list and get any comments..
--
Rohan Lloyd
-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge
|
