On Tue, Aug 19, 2014 at 07:12:30PM +0400, Dmitry Shachnev wrote: > While this is not directly related to the transition, can you please > use the correct package naming for python packages (at least in > future)? > > For example, you recently (~ 2 days ago) added a new binary package: > > * New binary package python-gtk-media3.0 for wx.media. (Closes: #722687)
There's actually a typo in the changelog entry - the new module was really called python-wxgtk-media3.0, which at least includes "wx". > Per the Python policy [1], it should have been named python-wx.media, > not python-gtk-media3.0 (we have these naming rules so that it's > easier to guess which package a module is in). > > [1] > https://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-package_names Sorry for not following the policy - I hadn't really thought about the name much, and just named it liked the C++ runtime for the media stuff. However, python-wx.media wouldn't work with how the parallel installs of different wxPython release series are handled - you can select the version (or versions) of wxPython your app supports via the wxversion module, and then "import wx" will import one of those (or fail if not available). The transition to a new wxPython version would be a lot more painful without the ability to parallel install. And the wxversion mechanism is provided by upstream, so it is something which upstreams of packages using wxPython will expect to be available - renaming the wx modules to include the version would mean we'd have to patch a lot of packages. So the binary package name needs to include "3.0" (while there's no package of wx.media for wxPython 2.8, that's mostly because it would have a very short life at this point, and there will be one for wxPython 3.2). It probably should include "gtk" too, as you can build other flavours of wx on Debian, such as wxX11 and wxMotif, and there's apparently a wxQt in the works: http://docs.wxwidgets.org/trunk/page_port.html#page_port_wxx11 http://docs.wxwidgets.org/trunk/page_port.html#page_port_wxmotif http://wiki.wxwidgets.org/WxQt We don't currently package any of these for Debian, but I can see that once it's a bit more mature, wxQt would be desirable to provide a more consistent look-and-feel for wx-apps on a KDE desktop, and perhaps wxX11 would be useful for lower-end systems. I don't see anything obvious in the Python Policy about what to do when multiple binary packages can provide the same module. I guess something like python-wx.media-wx3.0-gtk would be a better choice (but probably too much pain to change at this point for 3.0). Perhaps the new package should at least have "Provides: python-wx.media" (and python-wxgtk3.0 have "Provides: python-wx"). That would make it easier to locate them from the module name, and allow packages to depend on wxPython without hard wiring a particular version (or port). BTW, I'd welcome involvement from Python people in maintaining wxPython. I'm not a big Python user myself (as you can probably tell). In 3.0, wxPython is a separate source package to the C++ wxWidgets library, which has simplified that packaging significantly. Cheers, Olly -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140823033832.gb10...@survex.com
