Bug#430422: Changing omniorb4 source package name (was: Re: Bug#430422: omniorb4: Out of date / python2.5 transition)
On Thu, Oct 18, 2007 at 02:57:34PM +0200, Thomas Girard wrote: > Having thought about this again for a while, I'm no longer convinced we > should change the source package name. Indeed, the API was changed, but > we are not going to support both omniorb4.0 and omniorb4.1. > > omnievents, which build-depends on libomniorb4-dev and libcos4-dev, > still compiles fine with omniorb4.1, so a binNMU will suffice. > > Am I missing something? People might depend on the API out of tree and thus applications might break severely[0] when the package is upgraded? Kind regards, Philipp Kern Debian Developer [0] I don't know how much the API changed. I guess that the standarised CORBA API is still supposed to work as before? signature.asc Description: Digital signature
Bug#430422: Changing omniorb4 source package name (was: Re: Bug#430422: omniorb4: Out of date / python2.5 transition)
Hi all, > is the question if it's (intended to be) fully API compatible, then the > source package could just me updated. > > > The library packages do change name (from foo4 to foo4-1) due to the > > soname change, so anyone depending on it (i.e. omnievents) will be > > broken until they are rebuild. Not entirely sure how that is managed > > normally... I'll try and look more into that. > > Fine, an ABI change. Having thought about this again for a while, I'm no longer convinced we should change the source package name. Indeed, the API was changed, but we are not going to support both omniorb4.0 and omniorb4.1. omnievents, which build-depends on libomniorb4-dev and libcos4-dev, still compiles fine with omniorb4.1, so a binNMU will suffice. Am I missing something? Regards, Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#430422: omniorb4: Out of date / python2.5 transition
Hi Floris, on Thu, Oct 04, 2007 at 03:06:18PM +0100 you wrote: > I must admit I only use omniORB through omniORBpy, so don't really > know the anser. I had a look in the release notes and documentation > but didn't find anything explicitly, so I've asked this on the > omniorb-users lists. is the question if it's (intended to be) fully API compatible, then the source package could just me updated. > The library packages do change name (from foo4 to foo4-1) due to the > soname change, so anyone depending on it (i.e. omnievents) will be > broken until they are rebuild. Not entirely sure how that is managed > normally... I'll try and look more into that. Fine, an ABI change. > No one said shared libraries are easy ;-) Me neither. ;o) It's nice to see work on updated omniORB packages! Kind regards, Philipp Kern Debian Developer signature.asc Description: Digital signature
Bug#430422: omniorb4: Out of date / python2.5 transition
On 04/10/2007, Philipp Kern <[EMAIL PROTECTED]> wrote: > On Thu, Oct 04, 2007 at 02:19:30PM +0200, Thomas Girard wrote: > > But you're right, we'll need to check if it's possible to upgrade > > without breaking existing applications. If it's not we'll probably have > > to package this in a separate source package. > > That was exactly my question. I must admit I only use omniORB through omniORBpy, so don't really know the anser. I had a look in the release notes and documentation but didn't find anything explicitly, so I've asked this on the omniorb-users lists. The library packages do change name (from foo4 to foo4-1) due to the soname change, so anyone depending on it (i.e. omnievents) will be broken until they are rebuild. Not entirely sure how that is managed normally... I'll try and look more into that. No one said shared libraries are easy ;-) Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#430422: omniorb4: Out of date / python2.5 transition
On Thu, Oct 04, 2007 at 02:19:30PM +0200, Thomas Girard wrote: > Floris is currently working on packaging omniorb 4.1 (see [1]). > If I recall correctly, omniorb 4.0 is *not* compatible with Python 2.5, > so in order to be able to provide python 2.5 modules for omniorb we need > to move forward to omniorb 4.1. I know that, we use a backport of the *flub* packages internally together with Python packages recompiled for python2.5. > But you're right, we'll need to check if it's possible to upgrade > without breaking existing applications. If it's not we'll probably have > to package this in a separate source package. That was exactly my question. Kind regards, Philipp Kern Debian Developer signature.asc Description: Digital signature
Bug#430422: omniorb4: Out of date / python2.5 transition
notfound 430422 4.1.0-1~flub1 found 430422 4.0.6-2.3 thanks On Thu, Oct 04, 2007 at 11:55:28AM +0200, Philipp Kern wrote: > Hi Floris, > > On Sun, Jun 24, 2007 at 01:19:10PM +0100, Floris Bruynooghe wrote: > > Attached is the .diff.gz against the upstream omniORB-4.1 tarball that > > does the required work. It fixes almost all of omniorb4's outstanding > > bugs too as added bonus and should only need minor changes for adoption > > in Debian itself. > > are omniorb 4.1 and omniorbpy 3.0 fully compatible to 4.0 and 2.X? I.e. > do we have to expect that an upgrade breaks existing applications? Floris is currently working on packaging omniorb 4.1 (see [1]). If I recall correctly, omniorb 4.0 is *not* compatible with Python 2.5, so in order to be able to provide python 2.5 modules for omniorb we need to move forward to omniorb 4.1. But you're right, we'll need to check if it's possible to upgrade without breaking existing applications. If it's not we'll probably have to package this in a separate source package. Thomas [1] http://alioth.debian.org/projects/pkg-corba -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#430422: omniorb4: Out of date / python2.5 transition
Hi Floris, On Sun, Jun 24, 2007 at 01:19:10PM +0100, Floris Bruynooghe wrote: > Attached is the .diff.gz against the upstream omniORB-4.1 tarball that > does the required work. It fixes almost all of omniorb4's outstanding > bugs too as added bonus and should only need minor changes for adoption > in Debian itself. are omniorb 4.1 and omniorbpy 3.0 fully compatible to 4.0 and 2.X? I.e. do we have to expect that an upgrade breaks existing applications? Kind regards, Philipp Kern Debian Developer signature.asc Description: Digital signature
Bug#430422: omniorb4: Out of date / python2.5 transition
Package: omniorb4 Version: 4.1.0-1~flub1 Severity: normal Tags: patch Hi As per http://lists.debian.org/debian-python/2007/06/msg9.html we should be preparing for the python2.5 transition. As it happens python-omniorb2 needs to be upgraded to omniORBpy-3.0 to work with python2.5 due to the fact that it is an extension module and the exceptions have changed in C. However omniORBpy-3.0 requires omniORB-4.1, hence omniorb4 needs an upgrade too. Attached is the .diff.gz against the upstream omniORB-4.1 tarball that does the required work. It fixes almost all of omniorb4's outstanding bugs too as added bonus and should only need minor changes for adoption in Debian itself. Hope this can ge integrated quickly. Also feel free to contact me if you're unhappy with this, I messed something up etc. I'm willing to help keep omniorb in good shape. Regards Floris -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-laurie.2 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages omniorb4 depends on: ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libgcc11:4.1.1-21GCC support library ii libomniorb4-1 4.1.0-1~flub1 omniORB4 - CORBA ORB - libomniorb4 ii libomnithread3c2 4.1.0-1~flub1 omniORB4 - CORBA ORB - libomnithre ii libstdc++6 4.1.1-21 The GNU Standard C++ Library v3 omniorb4 recommends no packages. -- no debconf information omniorb4_4.1.0-1~flub1.diff.gz Description: Binary data
