Hi Dima, On Fri, Feb 10, 2017 at 07:42:39PM -0800, Dima Kogan wrote: > Andreas Tille <[email protected]> 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 <[email protected]> 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
