[Pkg-corba-devel] omniorb4 package name change

Thomas Girard thomas.g.girard at free.fr
Sat May 10 15:27:37 UTC 2008


Hello Floris,

On Thu, May 08, 2008 at 09:14:14PM +0100, Floris Bruynooghe wrote:
> I've commited the changes needed to change the package name to just
> "omniorb" instead of "omniorb4".   If you think it looks good then I'd
> like to add the PDF and PS documentation to it before we upload
> though.

It looks good, thanks for working on this! A few remarks:

 * new packages have to conflict *and* replace existing ones; see [1].
   So for instance omniidl should read:
     Package: omniidl
     Architecture: any
     ...
     Conflicts: omniidl4 (<< 4.1.2-2)
     Replaces: omniidl4 (<< 4.1.2-2)

 * init.d scripts have to handle this transition for omniorb-nameserver;
   i.e. handle the /var/lib/omniorb4 -> /var/lib/omniorb and the
   /var/log/omniorb4-nameserver.log -> /var/log/omniorb-nameserver.log
   move.
 
 * we can't rename the source package from omniorb4 to omniorb yet.
   We need to wait for another upstream release to do so, because the
   source package name is related to the .orig.tar.gz name and we don't
   need to upload another .orig.tar.gz until there's a new upstream
   release. Besides, renaming the source package disturbs the PTS and
   the BTS. (I once told Raphaël I'll work on renaming for the PTS but
   so far I haven't.)

> One issue is with omniidl4-python which is build from python-omniorb.
> I think it's best if we upload change that too.  But it is suggested
> by omniidl, so that would require a simultanious upload (and possibly
> be a broken dependency for a few days)?

The new omniidl should indeed suggest omniidl-python. It will not be
possible to satisfy this Suggests: until python-omniorb is changed too.
But this will not prevent omniidl installation, as a Suggests: is not a
strong requirement.

>                                          (If we do this and send
> python-omniorb through NEW anyway, I'd like to take the opportunity to
> add a python-omniorb-doc package.)

Yes, please go ahead.

> Both python-omniorb and omnievents will need to change their build
> dependencies next time they get uploaded in any case.

Right.

> Lastly I noticed that no package seems to depend on libcos.  Is this
> library only of interest if you're developing a C/C++ CORBA
> application then?

libcos4-1 contains stubs and skeleton code generated from the IDL
provided in the omniorb-idl. This code *could* be used by omnievents for
instance -- but so far omnievents recompile these itself, so it does not
link against any library from libcos4-1.  It's quite handy to have these
libs when you develop a C++ CORBA application relying on well known
CORBA services: you don't have to generate stubs yourself.

Regards,

Thomas

[1] http://wiki.debian.org/Renaming_a_Package



More information about the Pkg-corba-devel mailing list