[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
RE: running external scripts from rpm install
- From: James Olin Oden <joden malachi lee k12 nc us>
- To: rpm-list redhat com
- Subject: RE: running external scripts from rpm install
- Date: Mon, 11 Aug 2003 07:41:05 -0400 (EDT)
On Mon, 11 Aug 2003, Srinivas BC wrote:
> Just wanted to explain my problem here since it is related. I am trying to
> port an svr 4 package to Linux. I am in addition to calling external scripts
> am trying to find a way to call these scripts during install. I have to call
> not at %pre , %post , %preun or %postun want to call during installation. as
> per my understanding that there is no straight way in rpm. Is there any
> workaround ?
>
> James since I thought your solution given to Galit's problem could help mine
> too. I request if you could you add few more details regarding solution 2 as
> I could not grasp it completely. To be specfic I did not get " insert them
> into the spec file with the appropriate scriplet" means please if you could
> be more elaborate it would help solving my problem.
>
Basically, I was suggesting going to two stage process of building your
rpms. The first would take template for a spec file (that had been
partially filled) and insert into by whatever means (sed, awk, perl,
python, m4, ect.) the external scripts a scriptlets. So say you had
a script called postinstall like in solaris land, then when the template
specfile was expanded it would be inserted into the spec file as:
%post
#
# All the text of your script.
What ever script written to do this insertation would of course know about
all the standard solaris scripts and what tag they should appear as
in RPM.
That said, there is an area where Solaris packaging does not have a one
to one mapping to rpm, at least as far as I know. When you do simple
installs, or erases of packages they are quite similar, but rpm
also supports a package upgrade. What this does is
install the newer package running its install scriptlets, and then
erase the old package running its install scriptlets. This means that
all install/erase scriptlets must be able to determine the context
they are in; are they being ran in an install, upgrade, or erase?
To deal with this RPM passes to the scriptlet arg1 the number of instances
that will be in the database after the operation is completed. So for
upgrade scripts this is:
1 install
2 upgrade
and for erase scripts:
0 erase
1 upgrade
The reason I mention all this, is because if you don't intend for your
scripts (especially your erase scriptlets) to be ran in an upgrade, but
only when the package is first installed, and finally removed, then
your pre-processor will have to work some other magic to make sure your
scripts are only executed in an initial install/final erase.
So on an install script you could end up with:
%post
[ $1 != 1 ] && exit 0
#
# All the text of your script.
And likewise for erase scripts:
%preun
[ $1 != 0 ] && exit 0
#
# All the text of your script.
Cheers...james
>
> Thanks for any feedback.
> srini.
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
[]