Installer behaviour 6.1.0 - different to previous versions?

2 posts / 0 new
Last post
Offline
Last seen: 2 years 3 months ago
Joined: 09/11/2014
Posts: 6
Installer behaviour 6.1.0 - different to previous versions?

Dear RTI-Community,

 

I ran the new DDS 6.1.0 installer on a Debian 11 (x64) and observed different behavior that I was used from the previous installers (5.X.X, 6.0.X) - more detail below, but my question is if this is intended and RTI follows a new approach.

 

In the previous versions I would run the rti_connext....-x64Linux.run. In order to have if for multiple users I would install it with "sudo" and by default it would go into the "/opt/rt_connext_dds_X.X.X folder", later on I would install the package for the architecture I want to build for with the package installer.

 

After being finished any user on the system was able to run via command line without being sudo the tools in bin, spy, ddsgen, etc. without any issues. Same for the build process the cmake support files and the include files can be accessed from everyone despite that he/she is not sudo when working with the IDE and compiling... 

 

With the new version (6.1.0)when installing as local user it works fine, but when installing it as sudo the rights in the install folder are very restricted. I can not call as a normal user the spy, the CMake module can not be loaded and the cmake find package process fails because it can not access the rti_versions.xml due to insufficient rights. These issues cascade through the whole build, reading include files, invoking the ddsgen etc.

 

Is this intended and RTI wants to encourage the local user installation? For me, the "old" way was very handy since per user only one install is needed. Currently, the tools can be accessed only by desktop by the user when not sudo, but for command line it would need to be sudo but this is not practical while developing in addition to the issues with the build process. I made it work stepwise by "brute force" changing permissions on the RTI subfolders, but this is not a good way since sometimes it is good if certain configs are protected.

 

I would be happy if you could comment, also if this could be my local installation mishap or maybe even a bug.

Cheers,

Thomas

 

Organization:
Howard's picture
Offline
Last seen: 1 day 2 min ago
Joined: 11/29/2012
Posts: 565

Sorry, you'll probably have to submit a question to RTI's support team if your project has a support contract.  If not, I can put you in touch with the RTI Account Team who can help answer your question...just send me your project details to howard@rti.com