Re: Sundials is way outdated
Just pushed some patches. Notes inline.
Andreas Tille <andreas@an3as.eu> writes:
> While I keep on wondering why you are not pushing to master your commit
> 26d465d9dff18866d0fe5a4ffa942e49771ef7e5 (or what you are refering to
> with "Fix pushed" does not address the problem). I can confirm that I'm
> now again able to build and that I fixed the issue in
> 4bb864e534142f1667dc17cad501ab5406ede032.
My git-fu was very confused for some reason. We're on the same page now.
The master should have the latest now. Or so I claim.
> There is a remaining lintian error which needs fixing:
>
> E: sundials source: version-substvar-for-external-package libsundials-serial-dev -> libsundials-serial
> N:
> N: The first package has a relation on the second package using a
> N: dpkg-control substitution variable to generate the versioned part of the
> N: relation. However the second package is not built from this source
> N: package. Usually this means there is a mistake in the package name in
> N: this dependency.
> N:
> N: Note that this warning can occur if the package name used in the
> N: relation contains a typo. In this case, correcting the typo should
> N: remove the warning.
> N:
> N: Severity: important, Certainty: certain
> N:
> N: Check: version-substvars, Type: source
> N:
My lintian runs weren't showing this, but this was an oversight. I'm
removing the reference. Look at 4f884c118ddc87241e3053e3a1ba20e52154aacd
and debian bug #701146.
> 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.
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? How about a libsundials-dev and a
libsundials1 that has everything? 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.
I need to actually try to build an application using these packages to
see what that requires, but don't have time today.
>> > What do you mean by "the ones that are already in Debian"? I think
>> > if there is something in previous package versions we should keep
>> > those features.
>>
>> "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.
>> Also, I just pushed a patch into master_optional_stuff_enabled to turn
>> on libhypre support as well.
>
> Again: Pretty please merge master_optional_stuff_enabled into master and
> lets push a feature complete package to experimental.
Yes. Things were confused. I think they aren't anymore.
Reply to: