Re: Conflicting omniORBpy and PyORBit

...
> If you have two Corba implementation, obviously you must do something to
> indicate which to use.

For Linux RPM packaging, I'm inclined to break off omniORB's top-level 
CORBA.py into a separate RPM to make this conflict manageable. Not sure 
what to call the package; we currently have

  omniORBpy
  omniORBpy-devel
  omniORBpy-doc

How about "-boot" or "-toplevel" or "-default" or ?? Perhaps the 
"omniORB.pth" which is installed by the RPMs at the top level should be 
in this same category, since it exposes omniORB/COS IDL stubs at the top 
level, leading to possible conflicts with another ORB. Suggestions and 
comments?

Duncan suggested having omniORB/CORBA.py register itself as "CORBA" so 
that only the first reference needs to have the "from omniORB". That 
sounds interesting; should we move forward on that also? We *could* also 
modify sys.path to expose omniORB/COS *only* if omniORB/CORBA.py is 
loaded (eliminating omniORB.pth altogether). Comments?

                  - Tom


_______________________________________________
omniORB-list mailing list
omniORB-list@xxxxxxxxxxxxxxxxxxx
http://www.omniorb-support.com/mailman/listinfo/omniorb-list