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

Stuart D Gathman <stuart@xxxxxxxx> · Mon, 07 Feb 2011 20:31:06 -0500



    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.

  
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxxxxx
http://lists.rpm.org/mailman/listinfo/rpm-list