[Pkg-octave-devel] Sundials is way outdated

[Andreas Tille]

[Dropped personal addresses, added Debian Octave Group]

Hi,

On Sat, Jan 28, 2017 at 10:59:55AM +0000, Ghislain Vaillant wrote:
> >>1. The matlab/octave interface seems poorly supported (upstream may or may
> >>not drop it entirely), it uses a custom build script written in matlab
> >>(which requires modification to work with octave), which means we don't get
> >>multiarch easily. We could have dropped the interface, but it currently
> >>works (afaik), and the real solution (split it out and make it a proper
> >>octave package on octave-forge) would be time consuming and probably
> >>wouldn't happen before the freeze.
> 
> Then, it shall be dropped in the next iteration of the packaging. We don't
> need more volatile pieces of software being packaged.

BTW, if the octave module has some user base it might make sense to just
keep the octave part from the 2.5 version. In the Debian changelog the
package seems to have maintained initially by the octave group - may be
these should be involved into the discussion.
 
> >>I did consider uploading something to experimental in the mean time, but
> >>given there's a very real chance that what we uploaded to experimental
> >>would not match what would result from discussions with upstream, the
> >>package wouldn't of use to anybody, and probably create more confusion.
> 
> We would at least get feedback from the builders.

Definitely.
 
> >>If you do want get sundials into experimental, I'm happy to help, but I
> >>think efforts spent on packaging sundials are best used to get upstream on
> >>board with being an easier project to package (and to coordinate with
> >>Fedora and other distros so that upstream sees this as a push from distros,
> >>not specifically from Debian).
> 
> Why not, although if upstream is not so responsive as you made it sound,
> then I am not sure what you will be able to achieve.
> 
> Reminds me of our situation with FreeImage.

Finally we somehow need to follow upstream releases to be able to
package dependant software.  It makes sense to make them aware that
distributions are relying on some standards.  There is a Fedora
Scientific SIG and probably other distributions and making clear
that it is a common requirement would have advantages - even for
users who do not relay on distributed packages.
 
> Moving forward, I will noowner the ITA and let whoever is in charge take its
> ownership. Please communicate your progress there and on the team's
> mailing-list.

+1

Kind regards

        Andreas. 

-- 
http://fam-tille.de