> For TSP 0.8.4, I am ready to contribute for the packaging.

Ok let's go into the fast lane :=)
I did add yourself to the TSP project at Savannah.
(other TSP were OK for that).

You'll be able to fix my typo yourself
in the  0_8_3_x branch.

And ready for other contrib.

I send you a private e-mail for our "gentle commit policy".

Sorry for the delay on my side too.
Your patch is OK but was missing your credit
in the Changelog, I added it.

For now I created the br_TSP_0_8_3_x branch
and checked in your modified patch such
that you can test on your side that's Ok for you.

Then I'll tag it TSP_0_8_3-2.

> But I was wondering if a better solution wouldn't to completely
> remove the files used only for the packaging from this CVS tree
> and create a new one dedicated for the packaging file.

Good idea.
We should try to put this in place after TSP 0.8.4 release.
Would you like to contribute?
I think we may grant you commit right if you want to help
for this (and other subject if you want).

That's right but technically we must trace the updated

tsp.spec.in check-in update.

since we (unless I'm mistaken) we don't want
the /etc/ld.so.conf to go mainstream I would say
you need to branch the  tsp.spec.in file
and then release tsp-0.8.3-2.

Moreover since we do not release many differents
TSP binaries RPM you need to ship the source
tarball too tsp-0.8.3-2-Source.tar.gz which makes
it possible to rebuild a clean RPM for your favorite
target system.

So OK for not naming it 0.8.3.1 but tsp-0.8.3-2.
However you need a minimal branch in order to keep
it away from HEAD.

Then YOU MUST put a tag "TSP_0_8_3-2" because we must
be able to rebuild the very same package from CVS.
(tag is cheap so I think it's not worth avoiding it).

Sorry for being a little bit picky about those "packaging issues"
but the fact is:
  - we did never re-release without +1 in numbering
  - we did never make re-packaging release
  - we want to be able to rebuild ANY release from
    CVS and thus from source if needed.

Thank you for taking the time to discuss this.

OK for me.

branching with tag TSP_0_8_3_x
apply the patch from Olivier.

then do the release following the wonderful
release process:
tsp/ReleaseProcess.txt

with a minimal testing on Linux
(since it is essentially a Linux packaging release).

Considering the 0.8.3 Version for TSP, the shared libs are located in a directory under the /opt directory which is not a standard directory for shared library. (Not /usr/lib or /usr/local/lib described in the LD_LIBRARY_PATH variable or the /etc/ld.so.conf

Then, if I install an application from an RPM, my binaries will not found the TSP shared libs except if use the LD_LIBRARY_PATH or ld.so.conf.

If this operation is done in the RPM postinstall script, when the shared libs are installed there are directely locatable by the binaries without any manual action.

Note : I know that this modification would be acceptable only for the 0.8.3 Release and that issue is not applicable in 0.8.4 version (The libs are located in /usr/lib directory). But on my project it is not possible to use a CVS version for our production environment.

After a discussion with Frederik, I know that it would be not very intersting for you to release a 0.8.3.1 version only for this issue. But do you think it would be possible to release a version 2 for the RPM ? If you use my patch, only the SPEC file is impacted and so the RPM.

Good remark,

No it won't works on other systems.
However the patch only concerns RPM package
since it modifies the spec file which is the file
used to build the RPM.

So the proposed patch only concerns RPM based system
i.e. Linux distribution using RPM.

Will a mail on TSP ML in order to have comment.

This patch add postinstallation and preuninstallation commands in the spec file in order to include the TSP lib path into the UNIX LIBRARY_PATH.