Hi, On Tue, Jan 22, 2008 at 11:28:19AM +0100, Josselin Mouette wrote: > do you have any news about python2.5 support in wxwidgets ?
Well, the basic premise to date has been that the packages are built to use the default python version in Debian. Switching to python2.5 should be as simple as rebuilding from source. Installing such a build in parallel is a bigger problem, and I'm not sure if anyone has really spent much time figuring out how to support that in the context of the distro (or fully debated whether or not we want to add another layer of geometric growth in this way to the distro resources). People can already build an alternate 'flavour' of their own locally with whatever version of python they want, that they can install alongside the distro packages. But that doesn't work for the distro itself, unless you accept having 2 almost identical wx source packages in the archive, that differ notably only in one line of their build-deps. > The current state of the python package looks very bad, with no > support for multiple python versions, Perhaps you are just not seeing what you expect to see, there is support for any python version that upstream supports, in a form that was appropriate at the time that it was added. I'm not actually sure we do want to extend the '2 lib versions per release' policy to also automatically include x2 versions of every binding language... Here that extrapolates fairly easily to: 2(wxgtk) * 2(wxpython) * 2(wxperl) * 2(wxlua) * 2(wxruby) * 2(... package variants to build. We'd in effect get a 'wxDOS' virtual package for free as soon as the critical mass of ports is uploaded. > and a direct dependency on python2.4 which is the sign of > something wrong inside. This is a generated dependency that is created to match the default python version on the machine that prepares the first pristine source package for upload (or according to whatever a local builder forced it to). It's a constant once the package is uploaded because policy (rightly) says that it should be, and we don't want the buildd's to go making random choices about which version to use. If you change the build-dep to use a different python version, it's a different source package. And the things that used to work with the old one, may or may not now work with the new one, so that also is as it should be. I believe there is now a dh_something that can be used to replace this in future versions though. > If you need help on that issue, I can give a hand, but this package > cannot remain in this state. I'm not much of a python user in practice, so indeed anyone who is would be most welcome to help polish this up, but you might need to clarify a bit which particular state you think it can't remain in, because some of the things you are asking for above _are_ possible. And I'm not sure that packages for python2.5 need to coexist. If you want to test things for the transition, we can always upload wx for python2.5 to experimental, where anyone who is worried about the switch can test it. When python 2.5 is ready to be the default we just move the whole lot in as a single transition. What more do you need from 'multiple version' support in this context? Cheers, Ron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
