We are developing an application that would be used with RHEL. So far we had not prepared an installer for our application. So we were copying the binaries of our application in a directory, and updating system PATH variable to include that directory. This way, the commands of our application were available to be executed from any directory.
The time had now arrived to prepare RPM based installer for our application. I prepared a .spec file for this purpose. We decided to copy files of our application in a separate sub-directory under /opt directory. And not in /usr/bin directory. Right, /usr/bin is for distribution-managed normal user programs. But in our case, our own sub-directory under /opt was our chosen place.
I prepared the .spec file and used the rpmbuild command to create the .rpm file. All went well as planned, except one problem. Commands of our application that were present in /opt/our_app/ directory were not available in system PATH variable. To get this done, I added code in %post scriptlet. I updated value of PATH variable in .bash_profile file. But then, to get the change into effect, the .bash_profile file must be reloaded. I could not find a way to do that. source .bash_profile did not help. . .bash_profile did not help either.
After a lot of searching here and there, I came to know that reloading .bash_profile file is not possible during installation of the .rpm file. And updating the value of system PATH variable in .bash_profile file is not the right approach. The correct way is to create a symbolic link in /usr/bin/ directory, pointing to our command file. And removing the symbolic link at the time of un-installation of our package. So, in the %post scriptlet I created the required symbolic link.
%post
# Create symbolic link of eventd in /usr/bin/
ln -sf /opt/our_app/our_cmd /usr/bin/our_cmd
And in %postun scriptlet I removed the symbolic link that was created in /usr/bin/ directory.
%postun
# After removing the files, remove the symbolic link that was created in /usr/bin/ directory
rm -f /usr/bin/our_cmd
The %post scriptlet is executed just after the package is installed on the target system. The %postun scriptlet is executed just after the package is uninstalled from the target system.
The time had now arrived to prepare RPM based installer for our application. I prepared a .spec file for this purpose. We decided to copy files of our application in a separate sub-directory under /opt directory. And not in /usr/bin directory. Right, /usr/bin is for distribution-managed normal user programs. But in our case, our own sub-directory under /opt was our chosen place.
I prepared the .spec file and used the rpmbuild command to create the .rpm file. All went well as planned, except one problem. Commands of our application that were present in /opt/our_app/ directory were not available in system PATH variable. To get this done, I added code in %post scriptlet. I updated value of PATH variable in .bash_profile file. But then, to get the change into effect, the .bash_profile file must be reloaded. I could not find a way to do that. source .bash_profile did not help. . .bash_profile did not help either.
After a lot of searching here and there, I came to know that reloading .bash_profile file is not possible during installation of the .rpm file. And updating the value of system PATH variable in .bash_profile file is not the right approach. The correct way is to create a symbolic link in /usr/bin/ directory, pointing to our command file. And removing the symbolic link at the time of un-installation of our package. So, in the %post scriptlet I created the required symbolic link.
%post
# Create symbolic link of eventd in /usr/bin/
ln -sf /opt/our_app/our_cmd /usr/bin/our_cmd
And in %postun scriptlet I removed the symbolic link that was created in /usr/bin/ directory.
%postun
# After removing the files, remove the symbolic link that was created in /usr/bin/ directory
rm -f /usr/bin/our_cmd
The %post scriptlet is executed just after the package is installed on the target system. The %postun scriptlet is executed just after the package is uninstalled from the target system.
No comments:
Post a Comment