Re: Sundials is way outdated
Andreas Tille <tille@debian.org> writes:
> commit 26038269fc23ecf26abb85cd78fced63a3799a87
> Author: Dima Kogan <dima@secretsauce.net>
> Date: Fri Feb 10 19:26:13 2017 -0800
>
> I don't build the static libraries
>
> Usually we provide *.a files inside -dev packages. Do you have any
> reason not do this?
I haven't really seen this being the usual case, and my personal feeling
is that static libraries are detrimental. If you want to turn them back
on, be my guest and revert that commit.
> 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
>> The branch in master has the optional stuff disabled. There're a few
>> more commits in the 'master_optional_stuff_enabled' branch that has some
>> of the options turned on: the ones that are already in Debian.
>
> 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.
>> 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.
>> Furthermore, these packages don't think
>> too much about how to migrate from earlier installs. I.e. the
>> libsundials-serial-dev and libsundials-parallel-dev packages may not be
>> doing the right thing. I haven't used these enough to know.
>
> 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?
Andreas: you removed the documentation and repacked the sources. Where's
the licensing conflict? I didn't see it.
Also, I just pushed a patch into master_optional_stuff_enabled to turn
on libhypre support as well.
dima
Reply to: