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

[Robert de Vries]

On Monday 12 November 2007 09:14:54 pm Eric Noulard wrote:
> 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.

As I have heard no comments other than from you, I will commit the changes.
Reverting is always possible so no (permanent) harm is done.

>
> 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.

This article http://people.redhat.com/drepper/dsohowto.pdf from Ulrich Drepper 
is an excellent (but rather large) article how to create shared libraries.
Among many other things it explains version scripts and how/why to use them.

>
> > 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?

It is somewhat a matter of taste, but I find a large number of libs not very 
user friendly.
To combine the two smaller libs into the tsp_{consumer,provider} libs removes 
the need to specify two extra libraries at the cost of 20 kB.
Also when you read the article about shared libraries you see that you then 
can remove a large number of external symbols from the list of exported 
functions. This prevents users from using internal library functions. This of 
course works only if you combine the smaller libs into one. You can then 
specify the public functions as external and the rest as private.

                Robert