Re: Sundials is way outdated
Hi Dima,
On Sat, Feb 11, 2017 at 12:47:12AM -0800, Dima Kogan wrote:
>
> > The package builds for me but I get lintian errors:
> >
> > E: libsundials-cvodes2: symbols-file-contains-current-version-with-debian-revision on symbol AddIdentity@Base and 326 others
> > E: libsundials-arkode1: symbols-file-contains-current-version-with-debian-revision on symbol ARKBBDPrecGetNumGfnEvals@Base and 290 others
> > E: libsundials-cvode2: symbols-file-contains-current-version-with-debian-revision on symbol AddIdentity@Base and 209 others
> > E: libsundials-kinsol2: symbols-file-contains-current-version-with-debian-revision on symbol AddIdentity@Base and 189 others
> > E: libsundials-idas1: symbols-file-contains-current-version-with-debian-revision on symbol AddIdentity@Base and 331 others
> >
> > This either should be fixed or the symbols files can be dropped at all.
>
> Fix pushed to master_optional_stuff_enabled
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.
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:
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.
>
> > 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.
> >> I don't have enough experience here to know which should be on by
> >> default and which should not.
> >
> > I personally tend to enable as many features as upstream provides
> > and considers stable - so I see no point to artificially drop
> > features (and if we drop any this should be documented with the
> > reasons for doing so).
>
> I don't disagree, I just don't know what these things do. I don't
> actually use this library, it was a dependency of a larger project that
> I needed to build.
Lets simply assume these things do something sensible users might need.
If a user expects some feature which is missing that is just bad. If
a user realises that a feature is not working as expected a bug report
is the usual means to deal with this and we can try to tackle this in
the team.
> > Any volunteer for testing this. For sure we should provide a proper
> > migration path.
>
> The libsundials-serial-dev and libsundials-parallel-dev packages have
> some special meaning. Does anyone on this thread actually use these
> packages and can comment about whether this is done properly here?
I have no idea what this "special meaning" might be - but the dependency
from a not existing package is simply wrong.
> 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.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: