I am running a setup script as part of the installation of my RPM package (%post). The setup.sh script is a temporary script which I delete at the end of my %post section.

I would like to avoid including these installation files in the RPM database. I am new to building RPMs. I thought of using the %install and %clean sections, but was unsuccessful using su there. The spec snippet is below.

Preparing... ##################################################
file /appl/home/tuser/rpm/script/setup.sh from install of TIbEnvTibPrf-1.0-1 conflicts with file from package TIbAdmLdapCfg-1.0-1

%post
HOME=/appl/home/tuser/rpm
AUDITS=${HOME}/audits
FILES=${HOME}/files
SCRIPT=${HOME}/script
BIN=${HOME}/bin
LOG=${AUDITS}/rpm.log

echo "`date` INFO: installing package %{name} " >> ${LOG}

## install script
su - tuser -c "${SCRIPT}/setup.sh" >> ${AUDITS}/%{name}.log
if [ $? -ne 0 ]; then
echo "`date` ERROR: package %{name} installation failed" >> ${LOG}
else
echo "`date` INFO: package %{name} installed successfully" >> ${LOG}
fi

## remove your temp directories for future use
rm -fR ${HOME}/files
rm -fR ${HOME}/script
rm -fR ${HOME}/bin

Any compelling reasons why?


Why is running under another user necessary?


Are you building RPMs as root account user? That isn't best practice.


What does the script do? Can't it be detected and run on first run of the service or application?


Why should the success of installing the RPM depend on the successful run of the script?

The RPM is contains a java based installation which will be run as the application user. The installation files are large and are no longer needed after installation. I cannot just install the application on a build server and make the RPM from that. The installation must run on the server. There is an installation manager file that is basically like a registry for the software suite (ugly).

I need to run the installation as the application user, not as root. That is the reason for the switch user.

I build the application as the application user, not as root on a build server.

The setup.sh script runs the installation binary passing it the silent install file also included in the RPM.

If the setup.sh script fails then the RPM should fail, so that we know installation was not a success.

OK. I think the fundamental question here is: if you basically use RPM for temporary payload delivery and kicking off the actual install, then should you be using RPM in the first place? What's the added value?

Back to the problem of , why not rename setup.sh to %{name}_setup.sh (or use random value)? That way TIbEnvTibPrf_setup.sh and TIbAdmLdapCfg_setup.sh won't conflict. If that's not what you're looking for please post the .spec files and verbose install runs between BB code tags (for readability) or if it's too long tarball them up, U/L to some free hoster and post the D/L URI here.

You are correct this is an unorthodox approach, and RPM is only a delivery method (couldn't find a good example of this, except when a RPM does a make on the server). RPMs are our standard for software deployment the tools for distribution and config management at our shop is very mature for RPM. The SAs prefer it to always be in an RPM and I am trying to take advantages of these features.

Sounds like the right approach to use %{name}_setup.sh and continue to use the %post section of the spec file.

Continuing with this approach does pose a problem. The temp files used during installation are removed after installation. RPM has stored these files in the RPM DB, and these files are no longer on the system. What problem will this cause with a RPM DB being inaccurate?

This is why I was looking for a way to ignore some files from the RPM DB perspective or to a command to delete these files from the RPM DB along with the files on the file system.

I was looking for something similar to the Solaris command removef. Does RPM have such options or language?

Thanks again,
-Greg

No installf or removef.


Willfully neglecting standards should give you the same motivation to perform better as cattle get from prodding rods ;-p


How about packaging up your installation code as tarball and list that as the only %file and using a %post script to unpack it to a tempdir, install and remove the tempdir? This still violates the standard but it should get you going.

moooooo...hey watch it!

ROTFL! At least you haven't lost your sense of humour yet :-]

I built a RPM with no %setup, no %install and no visible %files.
I used the %ghost tag to keep certain files out of the RPMDB.
The payload being in %post, it does what I want it to.