Hi,
I had a similar challange. Our products are also not delivered as source.
We provide shell scripts for install and remove along with the package
content that includes pre-built binaries.
I felt I had to decide between two approaches in order to build rpm
packages of our products. The first choice was to modify all our product
source nodes (make files, adding "make install", etc.) to support building
of rpm packages from source code which the customer would never see. In
addition, every other product source node would require the same types of
edits/changes be performed again. Taking this course of action would take
extra time and create unnecessary life cycles for each product that needed
to support rpm. We only had one customer requesting rpm so I felt this
choice would result in more up front engineering effort than it was worth
and make it much harder to meet the desired schedule.
The second choice was to develop an rpm spec file for the needed products
that essentially used the existing product packages and their install
script from inside the rpm spec file. Most of our products are similar so
by developing a generic spec file that used variables at the top to set
product specifics (like product name, version, etc.) seemed the best way
to go.
What I ended up doing is using the %prep section of the spec file to setup
$RPM_BUILD_ROOT to contain the bare minimum linux filesystem content
(directories and files) required by our product install scripts. The
system directories and files that would get updated by our install script
needed to exist in advance of execution of the %install section described
below.
I then used the %install section to run our install script to install the
product in question to the $RPM_BUILD_ROOT. It helped that our install
scripts already supported relocatable root installations (i.e.
installations to a virtual root directory other than /). You should be
able to parameterize / in your install script to do the same thing.
Start by creating an empty directory, populate it with system directories
and files you know are needed by your install script, then try installing
your product to this directory. Once you know all the steps needed to
setup an empty directory as a virtual root directory for installation you
can adjust the %prep section to perform these steps automatically.
At the end of the %install section I removed any system files that were
updated by our install script. The sections of our install and remove
scripts that handled changes to system files were folded into the
appropriate %pre, %post, %preun and %postun sections of the rpm spec file.
You may also find that when rpmbuild runs it will complain about
unpackaged files located in $RPM_BUILD_ROOT as compared to the files in
your %files section. Some of the files may actually belong to your
package and need to be added to %files. Other files may not belong to
your package and are simply there to support installing your package to
$RPM_BUILD_ROOT in which case they would be candidates for removal from
$RPM_BUILD_ROOT at the bottom of the %install section after your install
script is done installing your product.
The %clean section simply cleans out $RPM_BUILD_ROOT. I took extra
precautions to make sure $RPM_BUILD_ROOT exists as a directory and is not
set to / before running "rm -rf $RPM_BUILD_ROOT". Although, if you build
your rpms as a jive user (not as root) as recommended at least your system
damage would be minimized if something went wrong. I decided to develop
as root since our install script required the user to be logged in as root
in order to execute. I used a freshly installed system to do my initial
rpm development so didn't care if something got whacked as it took less
than 40 minutes to wipe the disk and re-install (never needed to though).
Note: I initially did not use %clean at all as I needed to retain the
content of $RPM_BUILD_ROOT in order to correct problems while I developed
my process. I would manually wipe out $RPM_BUILD_ROOT when needed.
I did not use a %setup or %build section in my spec file.
What I ended up with was easily adapted to the other products that needed
to support rpm packages.
One of the items that surprised me about rpm that is worth mentioning
(shown via a script excerpt):
%preun
# rpm upgrades (-U) install the new package first then remove
# the old package which results in the old package's preun and
# postun scripts running last in an upgrade scenario. Therefore,
# check parameter 1 to see if this is an upgrade to a new version
# ($1 >= 2) versus a removal of the last installed version
# ($1 = 0). Skip the following if this is an upgrade so we
# don't break the new package installation.
if [ $1 -eq 0 ]
then
last package installed removal steps go here...
fi
The above is located in the %preun section of my spec file. Depending
on your requirements you may also need something similar in your %pre
section:
%pre
# $1 will be 1 if this is a first time rpm install and >= 2 if
# this is an upgrade (i.e. if there is already a package of the
# same name installed).
if [ $1 -le 1 ]
then
first time install pre-install steps go here...
fi
Welcome to the wonderful (and sometimes whacky) world of rpm. :-)
On Wed, 20 Jun 2007, Novick, Randy wrote:
> Date: Wed, 20 Jun 2007 15:38:34 -0500
> From: "Novick, Randy" <Randy.Novick@xxxxxxxxxxxx>
> Reply-To: RPM Package Manager <rpm-list@xxxxxxxxxx>
> To: rpm-list@xxxxxxxxxx
> Subject: ... binary RPM question ...
>
> Hi,
>
> This is my first post to the list, though I've been lurking for a few
> days.
>
> I have been reading Maximun RPM and a host of other howtos and I've got
> a .spec file in progress, but I'm confused about how to do something
> that appears to not fit so neatly into the documentation I've read.
>
> The challenge is this:
>
> We have our own build process that creates all the necessary object
> files on each of our UNIX platforms (there are three, and AIX and Linux
> are the two I'm interested in delivering via RPM). We cannot ship our
> sources to our customers, yet we would like to leverage the RPM database
> to track and manage what files get installed at the customer site.
>
> We have a packaging process that follows compilation which plucks all of
> the objects and library dependencies into a "runtime" directory that
> represents what the customer will have installed. This "runtime"
> directory is tarred up and gzipped and this is what we deliver to the
> customer as a release, also shipping a set of scripts alongside that
> handle the gunzipping and untarring of the deliverable, the creation of
> logdirs, the setup of config files and the tweaking of system settings
> necessary for getting things to run.
>
> What I want to do is to create an RPM that contains what I've compiled
> in the form of the gzipped tar I create, and also encapsulates the
> scripting necessary to untar, create dirs, setup configs and tweak
> settings in the .spec file.
>
> I'm stymied, though, as to how to use the rpmbuild dirs to achieve this.
> Which ones should I not use, if I'm not having the customer compile the
> code as a part of RPM installation? What steps in the .spec file can I
> skip? Do I get any advantage out of not pre-tarring-and-gzipping my
> build products? Which steps in the .spec file must I certainly use to
> contain my scripting?
>
> I've had a lot of experience with solaris packaging, so I understand
> preinstall, install, postinstall ... and preun, un and postun. Rpmbuild
> has got a lot more complexity, though, and appears to be more suited to
> open source deliveries than the kind of closed-source installs I'm
> trying to achieve.
>
> I'd appreciate some advice, and some help getting started.
> Thanks,
> -- R
>
>
>
>
>
> Randy Novick
>
> Software Configuration Management
>
> McKesson Provider Technologies
>
> randy.novick@xxxxxxxxxxxx
>
> (303) 926-2229
>
>
>
> Confidentiality Notice: This email message, including any attachments,
> is for the sole use of the intended recipient(s) and may contain
> confidential and privileged information. Any unauthorized review, use,
> disclosure or distribution is prohibited. If you are not the intended
> recipient, please contact the sender by reply email and destroy all
> copies of the original message.
>
>
>
Thanks,
Mark Sincerbox
Adax, Inc.
1-510-548-7047 x129
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
