patchTransport Sample Protocol - Patches: patch #6656, Add TSP path in /etc/


You are not allowed to post comments on this tracker with your current authentication level.

patch #6656: Add TSP path in /etc/

Submitter:  Olivier BONHOMME <ptitoliv>
Submitted:  Tue 21 Oct 2008 08:33:03 AM UTC
Category:  TSP Priority:  5 - Normal
Status:  Ready For Test Privacy:  Public
Assigned to:  ptitoliv Open/Closed:  Open

Jump to the original submission

Tue 23 Dec 2008 03:30:05 PM UTC, comment #16: 

Correction in branch 0_8_3_x on the spec file. The date format was incorrect for the last changelog line. (Month and day of the month switched)

Olivier BONHOMME <ptitoliv>
Group Member
Mon 22 Dec 2008 08:55:25 PM UTC, comment #15: 

Olivier is now in charge.

Eric NOULARD <erk>
Group administrator
Mon 22 Dec 2008 03:22:00 PM UTC, comment #14: 

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

Eric NOULARD <erk>
Group administrator
Mon 22 Dec 2008 03:14:56 PM UTC, comment #13: 

I made a checkout on the branch 0_8_3_x and there is a little problem with the spec file : The date format on the last changelog is not correct and this error prevents the RPM to be built.

The correct line should be :

  • Mon Dec 1 2008 ptitoliv <>

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

Olivier BONHOMME <ptitoliv>
Group Member
Mon 15 Dec 2008 12:27:00 PM UTC, comment #12: 

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

Eric NOULARD <erk>
Group administrator
Mon 01 Dec 2008 05:29:24 PM UTC, comment #11: 


Sorry for the delay but I had to manages several important issues on my project and I didn't have time to discuss about TSP.

You'll find a new patch for the SPEC FILE for the TSP

About the way to manage this evolution in CVS, I think your solution can be usable.

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.

With that solution, it would be easier to manage versioning for the main source tree : a new release with a new CVS tag will be made only when the sources of the software change.

For the packaging, we would pick up the correct packaging files and the packaging CVS module and apply it to the desired sources.

(file #16960)

Olivier BONHOMME <ptitoliv>
Group Member
Thu 13 Nov 2008 06:48:54 PM UTC, comment #10: 

That's right but technically we must trace the updated check-in update.

since we (unless I'm mistaken) we don't want
the /etc/ to go mainstream I would say
you need to branch the 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 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.

Eric NOULARD <erk>
Group administrator
Thu 13 Nov 2008 06:07:13 PM UTC, comment #9: 

After chatting with Frederik,I think it would be more logical to release a RPM 0.8.3-2.

Indeed,the TSP software doesn't change but only the packaging. So because there is no changes on the software, I think the tag is not really appropriate.

That's why I'd propose to release a RPM 0.8.3-2 which is a 2nd RPM containing the TSP 0.8.3 software.

Olivier BONHOMME <ptitoliv>
Group Member
Thu 13 Nov 2008 05:10:33 PM UTC, comment #8: 

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:

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

Eric NOULARD <erk>
Group administrator
Thu 13 Nov 2008 02:17:06 PM UTC, comment #7: 

Are we OK with:
- Branching 0.8.3
- Apply the patch
- Releasing a without any other testing than the one involving the patch?

Frederik Deweerdt <deweerdt>
Group administrator
Wed 12 Nov 2008 12:42:19 PM UTC, comment #6: 

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/

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

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

Olivier BONHOMME <ptitoliv>
Group Member
Tue 11 Nov 2008 11:04:12 PM UTC, comment #5: 

It seems weird for the app to do this. I'm OK with both proposals ( or rpath). That said, I'd like to make sure I understand the purpose of the proposal.
What's the use case?

Frederik Deweerdt <deweerdt>
Group administrator
Tue 11 Nov 2008 09:40:10 AM UTC, comment #4: 

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.

Eric NOULARD <erk>
Group administrator
Mon 10 Nov 2008 08:21:43 PM UTC, comment #3: 

Hello All

Although the idea to add path in seems to be nice on Linux, will it works on all the others target we use ?
As far as my memory is good, Solaris and VxWorks are still alive, FreeBSD and RETMS had a try, and Windows is ... still a joke :=)


TSP administrator <tsp_admin>
Group administrator
Mon 10 Nov 2008 02:19:24 PM UTC, comment #2: 

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

Eric NOULARD <erk>
Group administrator
Fri 07 Nov 2008 10:29:19 PM UTC, comment #1: 

Hi Olivier,

I'm not sure it is a safe modifications for all of us
Adding something to /etc/ is a system-wide

If ones have two applications linked against two differents
version of TSP it will be a painful modification.

May be a safest way to go is to enable full RPATH
usage for TSP lib?

With full rpath your application will be compiled within
full rpath such that you don't need the stuff
You may try the attach patch.

(file #16802)

Eric NOULARD <erk>
Group administrator
Tue 21 Oct 2008 08:33:03 AM UTC, original submission:  

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

Olivier BONHOMME <ptitoliv>
Group Member


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #16960:  tsp_0_8_3_2_patch_spec_file added by ptitoliv (1KiB - application/octet-stream)
file #16802:  tsp_full_rpath.patch added by erk (2KiB - text/x-diff)
file #16720:  patch_tsp_spec_in_fix added by ptitoliv (717B - application/octet-stream - New patch version (Fix on lib path))
file #16717:  patch_tsp_spec_in added by ptitoliv (713B - application/octet-stream)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by deweerdt (Posted a comment)
  • -email is unavailable- added by tsp_admin (Posted a comment)
  • -email is unavailable- added by erk (Updated the item)
  • -email is unavailable- added by ptitoliv (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.


    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-12-22 erk Assigned toerk ptitoliv
    2008-12-15 erk StatusNeed Info Ready For Test
        Assigned toNone erk
    2008-12-01 ptitoliv Attached File- Added tsp_0_8_3_2_patch_spec_file, #16960
    2008-11-10 erk StatusNone Need Info
    2008-11-07 erk Attached File- Added tsp_full_rpath.patch, #16802
    2008-10-22 ptitoliv Attached File- Added patch_tsp_spec_in_fix, #16720
    2008-10-21 ptitoliv Attached File- Added patch_tsp_spec_in, #16717

    Back to the top

    Powered by Savane 3.12