On 28/01/17 07:24, Andreas Tille wrote:
Hi, On Sat, Jan 28, 2017 at 03:57:40PM +1100, James Tocknell wrote:Dunno if you saw it, but I had packaged 2.6 - 2.7 inclusive (plus the old versions) at https://github.com/aragilar/debian-packaging-sundials.I'm sorry, but I do not see anything outside Debian Science git. I'd be super happy if we would start to join forces on https://anonscm.debian.org/git/debian-science/packages/sundials.gitLike Dima, I'm currently using the packaging, so it should work.I thought it would be the sense of having a common packaging team to not duplicate the work.
Not even that. The basic workflow would have been to get ownership of the RFA [1], convert to an ITA and update the status of your work there. This workflow should have happened regardless of the packaging team you were willing to work with.
None of this happened until yesterday. Debian has guidelines in place to avoid duplication of work, people just need to follow them.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798331
The reasoning for waiting till after the freeze is there's a number of things we need to sort out with upstream, and given their responsiveness trying to do this before the freeze seemed impractical. The issues as I see it are:
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.
2. Upstream has broken the ABI in every release without bumping the so number (this is the most time consuming part of packaging sundials), and don't seem to think/be aware that this is a problem. My packaging went ahead and did its own thing (given upstream's response), but that's not really a viable strategy in the long term. I also raised the ABI breaks on Fedora's bugtracker, but nothing's come of that.
That's definitely worrying and unfortunate. We can get away from it by bumping the soname of the shlibs packages on our own, but as always, it'd be better if upstream did its homework properly.
3. There are no real tests, there's some examples, we'd need to ask upstream for tests (if they have any).
This is bad too. Building the examples could be an autopkgtest to verify the -dev packages, but a test suite would be miles better.
4. Upstream does not communicate their plans, nor have a have an open bugtracker: for example, the first I knew of the 2.7 release (as opposed to them doing a bugfix release) was when they announced it on their mailing list.
Ack.
5. Upstream switched from using autotools to cmake, which lead them to drop sundials-config (script which produces the correct link flags) . As part of my packaging, I've created pkg-config files, but it doesn't help if upstream doesn't adopt them (or chooses to name them differently given the different configurations possible).
Do they generate a CMake package configuration at least? Otherwise, I wonder how upstream expected to have their libraries discovered by client projects.
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.
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.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.
Cheers, Ghis