> Take, for example, sharpmusique. I want to be able to browse the > iTMS. Since I don't develop with C# or Mono/.NET I don't know > anything about the different versions of each and I really don't care. > I just want the application to work. The package depends on a version > of mono that works, and I'm a happy user.
I was talking about libraries... sorry for not being clear enough. And... I don't know about non-library packages called python*-package (maybe there are some). I thought application packages are named as any non-python program. > Likewise you don't ask for different packages of kmail (or python), > one built with each version of gcc. If it works, you don't care :-). See above. > However, if the software is a library and the user of the software is > a developer, then the version of python may matter and you may have > reasonable use cases for having a 2.3 and a 2.4 version. I would be > highly skeptical if you also claimed that you need a 2.2, 2.1 and/or > 2.0 version. What I want is... the latest version, and maybe those versions that are needed to run some applications. I thing for debian it's 2.4 and 2.3, so you don't have to [be sceptical]. > A lot of libraries are provided this way. I don't think any > applications are. Some libraries aren't, because the maintainer > decided the return on investment for supporting a non-default version > of python is too low for the cost involved. The same misunderstanding... library packages, of course > Ideally there would be exactly one version of python, and exactly one > package for each of the extension modules and applications using > python. This is not really practical because python improves and new > versions become available. Developers (users of debian) will need > multiple versions of python to ensure that the products they develop > are compatible with the range of python versions they expect users of > their product will use. The compromise is that debian provides a > python package marked as the 'default' version. This is the 'exactly > one' version in the ideal scenario. In practice, other non-default > versions of python are provided as well. Individually the maintainers > of each package that uses python can choose to support only the > default python, or support the default and any other optional versions > they choose to support. An exception is if the default python is to > obsolete and their package only works with a newer version. That's what I would expect... but a python user (I mean programming language user / developer) must code for python 2.3 now, if he uses libraries such as wxWidgets or kid. Even if those libraries run perfectly on python 2.4. Python improves and developers want to code for the current version, not the old one, in my opinion. And, btw... the scheme you are describing would work ONLY if all libraries were named python<version>-package.... and default version in a metapackage. Maintainer cannot choose the dependency (working with several versions of python installed) for an application using wxWidgets... because there is no python 2.3 version and no python2.4 version.... He has to use the default version allways. So if you make (or package) wx applications there is only one version of python and all python<version>-library packages are of no use to you. > As I mentioned before, the real problem is that etch's default python > is still 2.3, which is now quite obsolete. If the transition to > making 2.4 the default were complete you would have nothing to > complain about :-). That's right.... But I'd like at least one way working... alright, there is one way working.... setup.py ;-) Pavel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
