need to know if packaging our application stack as an rpm is the right way to go

[Stuart D Gathman]

On 02/07/2011 07:38 PM, mark meyer wrote:
>
> Question: is packaging our application stack as an rpm - the right way
> to go?
>
> Background:
>
> we have a PHP, JBoss and Flex application stack that we currently
> package (via our build process) as a tar ball.  we distribute the tar
> ball on a CD or a thumb drive to our customers.
>
> the install / upgrade process for our application stack, is invoked
> from the command line.  the process then un-archives the tar (which is
> just a large directory structure), sets up some symbolic links and
> finally runs a perl script.  the main perl script then runs several
> other scripts (perl and bash)
>
> i have been asked to consider packaging our application as an rpm.
>
>
> initially - i stayed away from rpms because of the following:
>
> 1) i knew i would have to support Windows at some point and wanted to
> use a package format (either zip or tar) that i could use on either OS
> (linux or windows)
>
> 2) i would not be compiling source code, only laying down (or over
> laying) files and directories
>
>
> given the previous: can someone help me to understand if there is any
> advantage to moving our distribution to an rpm package structure?
1 - find a Windows package tool that uses a text file to define the
package.  Keep that in a packaging directory along with the RPM SPEC file.

2 - RPM doesn't compile source code at install time - it "lays down"
files and directories just like you want.
What does RPM give you over a tarball?

  a. When *building* the RPM package, you checkout a specific VCS
(Version Control System) tag, and build the RPM from that.  Thus, each
RPM version matches a corresponding VCS tag.  You can always look at
exactly the source that went into a customers installation when
diagnosing a problem.  (I would hope a Windows packaging tool would give
you this much also.)  rpmbuild makes it easy to always build from
pristine sources when building a package.  (You have to work at it to
avoid that.)  This is a VERY GOOD THING.  (Even if you don't realize it
yet.)

  b. RPM tracks dependencies.  You can divide your suite into optional
features, some of which depend on others.  You can specify a minimum PHP
version and other external dependencies.

  c. RPM can create your symlinks and such at install time with a
postinstall script.  (Windows installers do that too.)

  d. RPM can report which files have been modified from the installed
versions.  (It stores a hash of every installed file in a database.)

  e. Uninstall is clean, and tracks dependencies.

  f. High level package managers for RPM (Like Yum, Apt-rpm, uptodate,
etc) automatically download and install required dependencies if
needed.  (User installs your app, and PHP gets installed or updated if
they don't already have it.)  (Yes, yum asks for verification first.)

  g. You can query RPM to find out which package a specific file belongs
to.  There are many other useful queries to the package database as well.

  h.  RPM has a python (and C) API if you want/need to really customize
the install process.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-list/attachments/20110207/e9a7143c/attachment.html>