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 [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
