[Pkg-corba-devel] Remaining issues before uploading omniORB 4.1

[Thomas Girard]

Hello,

On Sun, Nov 11, 2007 at 10:09:45PM +0100, Thomas Girard wrote:
> Hmmm... Right, the internal headers have to be included. But I think
> we'll need to check again the internal headers differences between 4.1.0
> and 4.1.1, because the following scenario should either work or be
> forbidden by an appropriate mechanism (e.g. Conflicts):
> 
>  * install omniorb 4.1.0 packages and python-omniorb2 3.0 packages.
>  * update omniorb packages 4.1.0 to 4.1.1, but keep python-omniorb2 3.0.
>    The python packages should still work, because libraries in omniorb
>    4.1.1 claim binary compatibility with 4.1.0. But since python omniorb
>    uses private headers...

According to [1], the change to omniORB4/internal/inProcessIdentity.h,
which added virtual void* ptrToClass(int* cptr), in omniORB 4.1.1 is not
binary compatible with omniORB 4.1.0. Maybe this file is not used in
omniORBpy, but it's safer to think internal ABI has changed between
4.1.0 and 4.1.1.

So what we'll need to do when update from 4.1.0 to 4.1.1 is:
 1. make omniORBpy 3.0 Build-Depends on:
    libomniorb4-dev (>= 4.1.0), libomniorb4-dev (<< 4.1.1)
    (or Build-Conflicts with libomniorb4-dev (>= 4.1.1))
 2. bump the shlibs file for omniORB libraries between 4.1.0 and 4.1.1
 3. make omniORBpy 3.1 build-depend on libomniorb4-dev (>= 4.1.1-1)

But first things first, let's upload omniORB 4.1.0. I plan to test
update from 4.0.6 this week-end, and if I can fix the other issue with
the naming service you've reported, I'll upload it.

Thanks,

Thomas

[1] http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++