Re: Sundials is way outdated
Hi Dima,
On Sat, Feb 11, 2017 at 12:47:12AM -0800, Dima Kogan wrote:
>
> 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 library packaging guide recommends static libraries for the -dev
package. It is correct that dynamic linking is prefered and if the
upstream build system makes trouble to create both versions its probably
fine to skip the static library but explicitly excluding these is wrong.
(I think the last discussion about this was in the end of last year on
debian-devel.)
So I reverted this and pushed.
> > 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
I tried to merge master_optional_stuff_enabled branch into master
but this does not build since
Package PETSc was not found in the pkg-config search path.
May be that's what you wrote below?
> >> 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.
So is there something restricting the features of sundials and should
we package this?
> >> 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.
I do not think that a maintainer should switch of features that are
not needed in own projects. We should try to provide a full featured
package to our users. If there might be some issue users can report
this in a bug report.
> > 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.
PDFs without sources that are enabling us to recreate the docs are
considered as binary without source. I have not found any sources
for the docs - but may be I'm wrong here. If I remember correctly
this was also done in the 2.5.0 series.
> Also, I just pushed a patch into master_optional_stuff_enabled to turn
> on libhypre support as well.
I'd be more happy if we work on a full features master branch that
would be a release candidate.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: