[postgis-devel] liblwgeom symbols exported by postgis module

[Bas Couwenberg]

On 2015-10-01 12:16, Sandro Santilli wrote:
> On Thu, Oct 01, 2015 at 11:17:55AM +0200, Bas Couwenberg wrote:
> 
>> The only way your theoretical case makes sense is for the newer
>> version. Debian won't rebuild the postgis 2.1.6 package when 2.1.8
>> is uploaded to the archive. The strict dependencies on the exact
>> binary version make sure that the liblwgeom-dev package pulls in the
>> the same liblwgeom version, liblwgeom-dev (2.1.8+dfsg-4) Depends:
>> liblwgeom-2.1.8 (= 2.1.8+dfsg-4), and liblwgeom-dev
>> (2.2.0~rc1+dfsg-1~exp1) Depends: liblwgeom2 (=
>> 2.2.0~rc1+dfsg-1~exp1).
> 
> Alright, so what would happen right now on a security fix (say in
> postgis 2.1.3) is that a _new_ package "liblwgeom-2.1.3" will be 
> installed
> in parallel to the existing "liblwgeom-2.1.2" so that both the 
> PostgreSQL
> module in package "postgresql-9.3-postgis-2.1" - dep. on 
> liblwgeom-2.1.2
> (>= 2.1.2) - and the binaries in package "postgis" - dep. on
> liblwgeom-2.1.2 (>= 2.0.0) - will still link against liblwgeom-2.1.2.so 
> ?

You need to drop your theoretical cases, they make no sense for Debian 
at least.

Security issues in Debian stable releases are handled by patching the 
existing package instead of uploading a new upstream release, as 
documented in the Debian Developer's Reference:

"
When an update is made to the stable release, care must be taken to 
avoid changing system behavior or introducing new bugs. In order to do 
this, make as few changes as possible to fix the bug. Users and 
administrators rely on the exact behavior of a release once it is made, 
so any change that is made might break someone's system. This is 
especially true of libraries: make sure you never change the API or ABI, 
no matter how small the change.

This means that moving to a new upstream version is not a good solution. 
Instead, the relevant changes should be back-ported to the version 
present in the current stable Debian release. Generally, upstream 
maintainers are willing to help if needed. If not, the Debian security 
team may be able to help.
"

http://www.debian.org/doc/manuals/developers-reference/ch05.en.html#bug-security-building

The new upstream release will also be uploaded to unstable which will 
trigger a transition because the SONAME changes requiring all dependent 
packages to be rebuilt with the new version (currently only spatialite, 
but grass also supports building with liblwgeom, but dealing with the 
circular dependency caused by spatialite depending on liblwgeom is 
sufficient motivation to not enable lwgeom support in other packages for 
the time being).

Kind Regards,

Bas