On Tue, Mar 21, 2006 at 12:10:54PM +0100, Martijn Pieters wrote: > Package: python-wxgtk2.6 > Version: 2.6.1.2 > Followup-For: Bug #353156 > > Please reconsider creating a python 2.4 version of the python-wxgtk2.6 > extensions. Though Debian itself may still standardize on python 2.3, many a > package already requires python 2.4. Debian python packages are meant to > support more than just the Debian scripts; there are indeed very few Python > extension for which there is only a python-2.3 packaging available. > > Moreover, many a package has not yet been ported to python 2.4, so if the > policy to only support the default Python version is upheld, following the > transition quite a few packages will be rendered useless.
a) You make this argument to the wrong person. I have no direct input to the Debian policy, so convincing me I don't agree with it isn't much help. Unless you are inciting me to violate it autonomously -- and I don't see any justification for that sort of action here. b) What makes python so special? We don't do this for other libraries as a permanent state of things. > The reality of Python is such that there are usually 2 major versions in > general use; That would seem to be Python's problem, not Debian's. Talk to them about their frequency of incompatible releases. If every library were to try to do this, where would we be? You don't even want to rebuild one library for yourself. Why do you think we should let Python double (or worse) our workload, in lieu of them improving their release management? > only by the time python 2.5 comes out python 2.3 use will fade, > and Debian python packages will generally support 2.5 and 2.4. Until then, the > majority of Python developers will expect a python 2.3 and a 2.4 version of wx > to be available on Debian. Now multiply this by every library that might have a new unstable version with some nice features that someone might use. Gets intractable fast, huh. > My particular usecase is that I want to install a 3rd party package (Picard, > http://musicbrainz.org/tagger/index.html), whose dependencies are all met by > Debian packages, except for wx, as Picard requires Python 2.4. Then nag them to do a backport, or do it yourself. As clearly, this isn't supported by any Debian release yet. It's future software. Which obviously was not developed for any existing Debian release. > To have to do a full compile of a python extension library for > one application is, frankly, a pain. And so me doing it instead, and loading up our infrastructure to support precisely zero applications in the distro is an improvement on that how? If we're being frank, python users expecting to be handheld though its quirks are a pain too. Many seem to have a fear of anything NOT Python, and an unreasonable expectation that others will do their work for them. Help me with my problem and it will be easier to help you with yours. There is no free ride on the bleeding edge. If you want to do something useful, build it for yourself and report to the relevant people that it all works, to whatever extent it might. If no one ever tests python2.4, how can we possibly know when it will be ready to enter the dist as the best default? That is a problem for python2.4 users. You are perfectly free (and welcome) to support them above and beyond what Debian does if this is important to you. I'll always happily take patches to ensure it builds from source. Anyone is free to subsequently distribute binaries to the interested. But simply moving your pain on to other people is not a viable option. Please think twice when you have the urge to nag others to do so. Gaining the ability to help yourself, will give you the chance to help others too. If there is not a single python user prepared to offer the 2.4 builds they do to others -- then I can only conclude that there are either no users, or they are singularly selfish and lazy. Proving that wrong through positive action can only help too. > If the application in question had used pyqt instead, I could have > installed it straight-away, as the python-qt3 packages *do* come in a 2.4 > flavour. Well, there is another option. Go port it to that if you think it will be better. Ron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
