Re: Sundials is way outdated
Hi Dima,
On Mon, Feb 13, 2017 at 09:54:05PM -0800, Dima Kogan wrote:
> > There is a remaining lintian error which needs fixing:
> >
> > E: sundials source: version-substvar-for-external-package libsundials-serial-dev -> libsundials-serial
>
> My lintian runs weren't showing this, but this was an oversight. I'm
> removing the reference. Look at 4f884c118ddc87241e3053e3a1ba20e52154aacd
> and debian bug #701146.
OK.
> > The thing is that there is no such binary package libsundials-serial
> > and I'm wondering why it has vanished (by accident or intentionally)
> > and by what the dependency should be replaced.
>
> I think I did most of this in the fall, but this was a forgotten piece.
> Latest in master has 3 -dev packages:
>
> - libsundials-dev
> Meta-package that pulls in all the -dev business
>
> - libsundials-nvecparallel-dev
> Parallel-only headers and libraries. Does not include header and
> libraries for the solvers. Depends on libsundials-nvecserial-dev
> because...
>
> - libsundials-nvecserial-dev
> Serial-only headers and libraries. Also includes all solver-specific
> headers.
>
> This is closer to what we want, but not 100% complete. I.e. if I want to
> build an application that uses cvode I presumably need the cvode headers
> and libraries. Do I also want the serial and/or parallel business?
>
> So there needs to be a way to install "all -dev stuff for cvode". Maybe
> we should be shipping libsundials-cvode-dev, but we currently do not
> ship such a package, nor do we ship the things that would go into it it
> ANY package.
I admit this all sounds pretty complex.
> Furthermore, there're a number of other libraries being built that we do
> not ship. We should be shipping all this stuff. Does anybody know why
> we're splitting these up at all?
If there is no convincing answer I would be in favour of not splitting
into so many packages.
> How about a libsundials-dev and a libsundials1 that has everything?
Sound sensible to me.
> Then we know we haven't forgotten to
> ship anything and the user know they haven't forgotten to install
> anything. This would probably require extra packages for the user to
> install, but I haven't yet looked to see how heavy that is.
In general I'm in favour of modularisation but in this case I'm missing
the point why it should be necessary. It makes packaging unnecessarily
complex for no real use. I do not think that installing some parts that
might be not used by the user would harm anybody while forcing the user
ito decide which packages might be really needed is time consuming and
error prone for the user in the end.
> I need to actually try to build an application using these packages to
> see what that requires, but don't have time today.
OK, take the time you need. Meanwhile we can wait for answers. If
there is no response to the package split I'd vote for merging
everything into two binary package: one with dynamic libs and one -dev
package featuring static libs and header files.
> >> "the ones that are already in Debian" means that some optional things
> >> use libraries that aren't in Debian, so I'm not turning those on.
> >
> > Would you please consider turning this those on anyway.
>
> Looks like there's only one such option: superlumt. If we turn this on,
> the thing won't build anymore: this build-dep is not in Debian.
OK. This should be documented in README.Debian. In case there might
be some wishlist bug report when somebody might request this feature
we can try to package the missing Build-Dep.
> Yes. Things were confused. I think they aren't anymore.
I think we are converging now to something that can be uploaded. Thanks
for your work on this.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: