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
_______________________________________________ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
