On Wed, 10 Nov 1999, Oliver Elphick wrote:
> The Hermit Hacker wrote:
> >> Is there any reason configure couldn't handle this?
> >
> >As simple as a '--with-corba=mico' configure option ... or, I would think?
>
> From the point of view of a package maintainer, I would much prefer a
> solution that separated the choice of Orb from the main build.
>
> If the choice goes into configure, I will have to pick a single Orb and
> build the Debian package for that, or else make packages for every
> Orb that Debian supports. It would be better if I could build a generic
> Orb-enabled PostgreSQL and produce a little pg-orb connection library
> for each Debian-supported Orb.
The same issue is true for the RPM's -- which ORB? If I'm on RedHat Linux, the
choice of ORB is going to depend upon the choice of desktops -- KDE or GNOME.
ORBit is packaged standard for GNOME -- KDE 2 is going to use something else --
now, my understanding of CORBA is quite limited -- Thomas, you have far more
experience, as you are actively developing CORBA stuff. If I choose to install
just KDE, KDE's ORB is going to be installed -- if I install GNOME, ORBit is
going to be installed. If I install both (the default), both ORB's will be
resident.
I can force the installation of a particular ORB through dependencies, but
that seems messy to me.
I CAN produce multiple sets of packages -- but that's going to cause all
manner of confusion for users.
Is it possible in the CORBA context to do what Oliver mentioned with a 'pg_orb'
abstraction layer to a generic CORBA-enabled postgreSQL??
It may seem like Oliver and I are getting the cart before the horse, but
the strategic decision of how to integrate CORBA into the system is going to
have wide-ranging repercussions for integrators.
--Lamar Owen
WGCR Internet Radio
1 Peter 4:11