[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Sundials is way outdated



Hi Dima,

On Fri, Feb 10, 2017 at 07:42:39PM -0800, Dima Kogan wrote:
> Andreas Tille <andreas@an3as.eu> writes:
> 
> > So could anybody please, pretty please commit something that really
> > results in installable packages?
> 
> I guess if you insist!

:-) thanks.
 
> I worked on this, and I claim the branch in master should build. Please
> look through the commits to make sure it all makes sense.

I stumbled upon 

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?

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.

> 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.
 
> 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).

> 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.
 
> But with those caveats considered, it SHOULD build and work. Tell me if
> it doesn't.

Thanks so far.  Any volunteer to join and test + enhance the packaging?

Kind regards

     Andreas.

-- 
http://fam-tille.de


Reply to: