[Pkg-opencl-devel] New OpenCL Package - Oclgrind

[James Price]

I’ve fixed the warnings about missing symbols and useless dependencies, and also the hardening issue. Thanks for pointing these issues out.

> About abi/api stability: once you make a new upstream release, will this be compatible with the existing liboclgrind-15.5.so?
> Consider new releases with varying amount of changes producing e.g.
>  15.5.1  (fix a typo/a segfault/a compiler warning triggered by gcc 7.0)
>  15.6    (do small changes)
>  16.0    (do huge changes)
> Will applications built against 15.5 be able to run with a new release without recompilation?
> When do we need to rename the libclgrind-XXX package?
> 
> For example, if a security bug is found, could you (as upstream maintainer) 
> provide a new upstream release that fixes this (and only this!) issue even on an old release branch?
> A stable Debian release with LTS support will have a lifetime of about 5 years ...
> so at some point this will several releases behind what's "current" oclgrind.
> Of course updating from 15.5 to 18.3 is not possible in stable, but a 15.5.2 api-stable and abi-stable bugfix-only release should be ok.
> That would have to build without requiring a package rename to liboclgrind-15.5.2.

I’m current anticipating 2-4 releases per year, but the API is relatively unstable at present, so I’m not sure whether I can guarantee any compatibility across these releases. This is why I picked the package version name to match the upstream release version - this conservatively assumes API incompatibility and would hence require rebuilds of dependent packages just in case. I wasn’t really sure if this was the right thing to do, and as you point out this makes things a little tricky with supporting an LTS stable release.

I could certainly introduce minor bug fix releases that retain API/ABI compatibility and hence don’t bump the package version (e.g. v15.5.1 as you suggested) to help with this.

Alternatively, we could try a more traditional SONAME scheme (e.g. starting with liboclgrind1) and only bump this for upstream releases if there really is an API/ABI change. I guess this would decouple the package version names from the upstream release versions, but maybe that’s not an issue.

Is there a general recommendation about which of these approaches is preferred for Debian?

James

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-opencl-devel/attachments/20150909/315eb750/attachment.html>