[omniORB] differentiating Cos services libs install

[Thomas Lockhart]

(restarting an old thread to follow up...)

>>> at the moment for example I need de CosPropertyService stuff and
>>> it's not in the libCOS4.so since it is not configured when
>>> building (from a .src.rpm).

I'll look into configuring that library for the RPM set.

>> Fractionating the RPM set into *very* small pieces...
> it's no problem on my desktop(s)/laptop/etc, but the AGVs I have to 
> install on also only have flashdisks...

How about having some "conditional building" in the spec file? We could
have it pruned down for embedded systems, without burdening desktops
with a huge number of options.

> The other is that libCOS[Dynamic]4 doesn't tell you what's in it. In
> my case I found out that CosPropertyService stuff is not included.
> That's the reason I'd like to have a split-up in libraries. BTW I
> think that an "omni" prefix should be used for COS lib(s) (e.g. 
> libomniCOS4 i.o. libCOS4) becase it only works with omniORB4. I'd
> prefer libomniCosPropertyService4, libomniCosNaming4, etc I too think
> that having all those omniORB4-Cos*[-devel]-4.0.3-2.i386.rpm will be
> somewhat too much... but at least one knows what is installed and
> what you have to link with.

We could move to having versioned libraries in general (e.g. 
libCOS.so.4.0.3) and you have a good point with possible name conflicts 
with short library names like "libCOS". Duncan, do you have a strong 
preference on this or would you accept patches from someone like Rene 
which adds in a "uniqueness field" like "omni"? How about moving toward 
library versioning at some point?

Johan, did you have a chance to test for SuSE the source RPM I posted? 
It now defines an omni user and omni group for running servers. I have 
them posted at

   http://www.fourpalms.org/pub/omniORB/devel/

Once they get shaken out we can ask Duncan to include the SuSE startup 
script (and the updated RH/MDK script) in the omniORB source tree...

                        - Tom