need to know if packaging our application stack as an rpm is the right way to go
geeky2 at hotmail.com
Tue Feb 8 17:48:46 UTC 2011
thank you very much for the feedback!
i did not expect to get nearly this many replies ;)
thanks for the great detail / dialog!
please see interleaved questions/ replies / comments
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
i do not understand this - are you saying that i can create an rpm distribution for windows?
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?
ok - thank you for the info
our application stack is mostly jar and .swf files that are generated from a large "top level" build (using ant). the final part of the build creates a large tar (or zip) file that we use distribute. our custom installation process then just un-archives and lays down the files on the box in the appropriate locations, then fires several perl scripts that do all sorts of things.
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.)
our build process is hooked in to svn. everything is tagged / versioned.
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.
agreed - this is an attractive aspect.
currently we maintain the dependencies on our own. we distribute our own JDK, JBoss, and other components. we even maintain our own customized openSuSE 11.3 distribution.
the customer installs our "spin" of openSuSE 11.3 then they turn around an install our application stack.
essentially we KNOW that everything works together because we own both sides of the street.
i know you could / can make an argument for this being either good or bad ;)
c. RPM can create your symlinks and such at install time with a
postinstall script. (Windows installers do that too.)
ok - this sort of stuff (and more) is handled in the perl scripts.
d. RPM can report which files have been modified from the
installed versions. (It stores a hash of every installed file in a
e. Uninstall is clean, and tracks dependencies.
ok - our current strategy for this is basic and prudent. these are production systems meant to sit in a server room pretty much as an appliance. we strongly discourage a customer from "backing out or un-installing".
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.)
ok - good information.
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.
understood. as mentioned above - since we more or less own both sides of the street, we know EVERYTHING there is to know about the composition of the install archive and the dependencies.
h. RPM has a python (and C) API if you want/need to really
customize the install process.
ok - our current interface is command line. we are going to incorporate new flex and php pages in to the application stack to handle upgrades.
it almost seems that our "planned" approach for the interface and the available API's for RPM are not compatible.
Rpm-list mailing list
Rpm-list at lists.rpm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Rpm-list