On Thu, Aug 07, 2014 at 11:08:54AM -0400, Yaroslav Halchenko wrote: > > On Thu, 07 Aug 2014, Christoph Schmidt-Hieber wrote: > > Applied upstream in > > > https://github.com/neurodroid/stimfit/commit/db161956 > > https://github.com/neurodroid/stimfit/commit/3d9305ff > > why not just to use alternatives in the above commit? with two copies of > control file it would be impossible to build neurodebian backports, and > in general -- duplication is not good ;)
You can still build backports, you just need to do this as part of the backporting process: cp debian/control-wx2.8 debian/control I already outlined the issues with using alternatives - quoting: > > > You can have alternates in Build-Depends, though the buildds will only > > > try to install the first alternative. So you could have something > > > like this which would work for uploads to unstable: > > > > Build-Depends: > > > libwxgtk3.0-dev | libwxgtk2.8-dev, > > > python-wxgtk3.0 | python-wxgtk2.8, > > > python-wxgtk3.0-dev | python-wxgtk2.8 > > > > This would also allow you to manually install the 2.8 packages and > > > build, but it wouldn't work for uploading to build against 2.8 in > > > wheezy backports, and nothing ensures you get a matching set (e.g. > > > libwxgtk3.0-dev + python-wxgtk2.8 satisfies this). For wheezy you'll just be able to backport as-is soon: > > > For wheezy-backports, wxwidgets3.0 is already backported, and I'm > > > intending to also provide a backport of wxpython3.0 shortly. I can't do this until wxpython3.0 migrates to testing though, which should happen in a day or two unless there's a serious problem discovered before then. > > I'm unsure whether we should release 0.13.19 including these changes > > or use your NMU instead given that we've just uploaded 0.13.18 - Yaro, > > what do you think? > > I would not mind NMU at all - but you would need to not forget to ACK it > in your next upload (so might end up more of work for you, depending on > how easy/complex is to cut a new release). A new upstream release would also benefit anyone else trying to use stimfit with wxWidgets 3.0 on Linux (or other Unix-like platforms), though I can understand reluctance to make a new release for a single change such as this one. In Debian terms it'd be good to get an updated stimfit package fairly soon, whether it is via a new upstream release, maintainer uploaded 0.13.18-2, or NMU. That way there should be plenty of time to shake out any issues prior to the jessie release freeze (Nov 5th). Cheers, Olly -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org