I guess that the real problem is a DSO and all the required configuration.
Why don't we roll a static mod_perl with apache: apache-mod_perl.rpm
and let all the troubles go. Just install this rpm, fire the server and
you are all set!
> Stas Bekman wrote:
> > When you install gcc*.rpm, do you complain about it? mostly not. Why?
> > because it's something that use without special needs. It's easy to make a
> > mod_perl RPM to handle some basic stuff. But if you are a real user of
> > mod_perl you want to discover many of its not so strightforward features,
> > then RPM doesn't fit you and you have to roll you own build
> >
> > RedHat makes RPMs the way it find correct. If it doesn't fit your needs
> > make your own RPM and contribute it to both RH and us, so others will be
> > able to use it. It's so simple.
>
> What I really need is something that I can just install on each server and have
> a copy of mod_perl which will work out of the box.. I'm not going to be hacking
> around with the mod_perl source in the production servers. If I'm going to do
> that, it will be on my development box.
>
> I'm just afraid that because people have been talking about so many problems
> with the Red Hat RPM and it's using mod_perl as an Apache DSO which is not
> recommended, I'm going to run into stupid problems somewhere.
>
> > Even better give us a SRPM, the user will have to build it himself, but
> > once he build ot from sources, it's promised that everything would work.
> > All it takes is:
> >
> > rpm --rebuild somepackage.src.rpm
>
> This produces a RPM built on the user's machine in /usr/src/redhat/RPMS and the
> whole build tree in /usr/src/redhat/BUILD, but when using a BuildRoot (which
> every package I've seen does) these /usr/src/redhat/BUILD files are going to be
> setup to install into the buildroot of /tmp/whatever, not where you actually
> want them.
>
> Perhaps instruct the user to do this, if they want to run their own build of
> mod_perl using the RPM as a starting point:
>
> rpm -i somepackage.src.rpm
> edit /usr/src/redhat/SPECS/somepackage.spec to remove BuildRoot line
> rpm -bi /usr/src/redhat/SPECS/somepackage.spec
>
> This way the user does not get an RPM built on their system, but the build tree
> in /usr/src/redhat/BUILD is setup to install into their live system (and just
> did).
>
> > I think it would help. If you succeed to build a good SRPM for a general
> > purpose usage, we ether can ask RH to put it in, or can put it on
> > sourcegarden or perl.apache.org - it's not an issue. Thanks!
>
> How about this way of thinking about creating an RPM: We think of mod_perl as a
> special DSO that we are not really allowed to use as a DSO, so we really want
> to just provide another Apache binary that has mod_perl built in.. So, when you
> want to enable mod_perl instead if inserting a "LoadModule" line in httpd.conf,
> you just change from "httpd" to "httpd-perl" in the apachectl script. The
> advantage is that this one binary can share the existing Apache documentation
> and DSO's from the RedHat Apache RPM. We just need to install what's different
> for the mod_perl binary, such as all of the Perl modules and the mod_perl
> specific documentation.
>
> Of course, if I distribute the RPM, the SRPM will come along too.
>
> - David Harris
> Principal Engineer, DRH Internet Services
>
>
>
_______________________________________________________________________
Stas Bekman mailto:[EMAIL PROTECTED] www.singlesheaven.com/stas
Perl,CGI,Apache,Linux,Web,Java,PC at www.singlesheaven.com/stas/TULARC
www.apache.org & www.perl.com == www.modperl.com || perl.apache.org
single o-> + single o-+ = singlesheaven http://www.singlesheaven.com
