Re: [Tsp-devel] [PATCH] RPM package fixes

[Eric Noulard]

2007/11/11, Robert de Vries <address@hidden>:
> >
> > You are very active on TSP those days keep going :=)
>
> If you are fine with the attached patch I will commit it.

Personnally I am.

I think as usual unless anyone step in and shout not to do so
(for good reason) then you can commit.

> I think we should add version numbers to the .so files and also add version
> scripts to the link lines of the .so files.

Yes we should version our shared libs.
but I have no experience in setting-up "clean" shared lib numbering
may you can expose us (or point us to appropriate URL) what
you would like to do, concerning shared lib numbering.

> I also would like to see that some of the .so files to be combined.
> To link a consumer application you have to link against 3 tsp libraries:
> tsp_consumer tsp_common and tsp_services.

Yes true, the splitting have its meaning:

tsp_common is the common set between provider and consumer
                      and should contains common data type definitions
                      (with associated functions/method)

tsp_services only contain ringbuf and tsp_time, ringbuf contains no code at all
                     since its all plain C MACROs. It could contains
"other" helper
                     code which is not specific to TSP.
                     As of today this a little bit empty lib.

tsp_consumer/provider contains specific consumer-side (resp. provider)
functions including command channel (ONC RPC, XML-RPC, etc...) and
data channel handling.

> The sizes of these libraries are:
> 175236  /usr/lib/libtsp_consumer.so
> 10546  /usr/lib/libtsp_services.so
> 12173  /usr/lib/libtsp_util.so
>
> For a provider the same libraries are needed (replace consumer lib with
> provider lib)

tsp_services may be merged into tsp_common but I would rather
keep tsp_provider/consumer separate from tsp_common unless
we have a good reason not to do so.

Could you tell us why you would rather have less shared libs?

-- 
Erk