|
hello all, thank you very much for the feedback! i did not expect to get nearly this many replies ;) hello stuart, 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 file. << 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 database.) << ok - >> 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. thank you, mark _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxxxxx http://lists.rpm.org/mailman/listinfo/rpm-list |
_______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxxxxx http://lists.rpm.org/mailman/listinfo/rpm-list
