I agree the build process should be improved to separate out files
better which will help making packages. I will keep it in mind at the
On Feb 4, 2005, at 12:46 AM, CLIFFORD ILKAY wrote:
> All this talk of configuration and deployment management reminded me
> of the
> problems I encountered while creating Webware RPMs. I have pretty good
> Mandrake RPMs for Webware and its docs but the mod_webkit RPM for
> Apache2 I
> created leaves something to be desired. Well packaged RPMs for Apache
> will not only install the DSO files in the right place but should
> httpd.conf and restart Apache to activate the configuration changes. I
> have a
> few problems with doing that for mod_webkit.
> I had to use the Mandrake RPM macros for doing make install as the
> included with Webware was never intended to be used to by a non root
> When I used the make install RPM macro to work around this, rpmbuild
> complained that marshal.so was created but not packaged. When I added
> it to
> the files list that RPM is supposed to install, the RPM built properly
> now I see mod_webkit.so and marshal.so in
> $buildroot/usr/lib/apache2-extramodules. If I just do make and make
> manually, I do not see marshal.so being installed anywhere. What is
> marshal.so? Can I just ignore it in my RPM and not install it at all?
> There are RPM macros for modifying httpd.conf and restarting Apache to
> activate the changes. However, if one is using MakeAppWorkDir to create
> working directories and running multiple instances of Webkit listening
> different ports, having the RPM modify the conf file would not make
> any sense
> as it could only do it for one instance. For each instance of Webkit,
> would have to be a corresponding entry in httpd.conf. This is where
> MakeAppWorkDir model of deploying applications makes things more
> particularly in a shared hosting environment, as it is does not seem
> like it
> would be easy to automate using RPM. Perhaps MakeAppWorkDir should be
> modified to make the necessary changes to httpd.conf and restart
> If we install from RPM, normally that would install the init script.
> If we are
> running multiple instances of WebKit, how would that work? We would
> have to
> have one init script per instance. This ties in with MakeAppWorkDir.
> the best approach would be to move all the functionality of
> MakeAppWorkDir to
> an RPM per Webware application. So, we would have RPMs like
> python-webware-common, python-webware-doc, mod_webkit2, and myApp1,
> etc. The myAppX RPMs would have to be created per web application.
> Once a
> skeleton spec file is created, it is not very difficult to flesh it
> out and
> build the RPM. This would make deploying one's web apps as easy as:
> 1. modify the skeleton spec file for the web app,
> 2. build the RPM for the web app using the spec file from Step 1,
> 3. run genhdlist to regenerate the RPM list for the urpmi repository,
> 4. add the urpmi repository created in step 3 to your urpmi media
> source, if
> you had not done so previously,
> 5. urpmi myApp1 myApp2...
> I have come to appreciate the flexibility of RPM after having to
> Webware applications from one server to another without using RPM. A
> application usually relies on other things, like a SQL back end, an
> ORB such
> as SQLObject, the egenix-mx utilities, db drivers like psycopg, etc.
> so it is
> not a trivial undertaking to install and configure all this stuff.
> RPMs has given me the ability to go from bare metal to a working web
> application in under an hour and have it work the first time, every
> I have not looked at WSGIKit to see how easy it would be to package as
> an RPM.
> I suggest to those who are developing WSGIKit, please pay attention to
> WSGIKit is packaged as a tarball. If there is clean separation between
> server components, docs, and Apache modules, it makes it much easier to
> package as an RPM. If we want the community to grow, having
> included with distros, or at the various least, as a contrib would
> Comments? Suggestions? Answers to my questions above?
> Clifford Ilkay
> Dinamis Corporation
> 3266 Yonge Street, Suite 1419
> Toronto, ON
> Canada M4N 3P6
> +1 416-410-3326
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> Webware-discuss mailing list
winston wolff - (646) 827-2242 - http://www.stratolab.com - learning by