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

Reply via email to