sure thing. I'll do some searching of the archives so I can add the
troubles of others to my own. Hold me to it :)
until David's last note, I didn't realize that the mod_perl RPM was a DSO
(now that I think of it, it makes sense, but since I wasn't able to get it
working...) Having a static apache-mod_perl.rpm build is probably the best
solution - rpm -i and off you go, which is what RPMs are all about. I don't
really know any of the ins and outs of building an RPM, but creating source
and installation trees that mimic the Guide's examples (or vice-versa) would
probably be a plus, if at all possible.
I appreciate everyone's input here...
--Geoff
> -----Original Message-----
> From: Stas Bekman [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, October 06, 1999 9:18 AM
> To: Young, Geoffrey S.
> Cc: David Harris; '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'
> Subject: RE: New mod_perl RPM really needed? (was: sourcegarden plug)
>
>
> You have nailed me down, I'll start the RPM problems section, but you will
> have to help me to report the known issues, since I use rpms for
> everything but apache/perl. And yes I would mention that in order to
> compile you need a compiler :)
>
> > well, I think that maybe we are getting a bit off topic now...
> >
> >
> > however, for those who wish to continue...
> >
> > I wasn't suggesting that RPMs in general were bad (as I said, I am RPM
> > impaired). To the contrary, I think that in order for Linux to succeed,
> it
> > needs an InstallShield type of tool - RPMs fill that need quite nicely,
> and
> > I still depend on them for stuff like Netscape, Gimp, etc. I didn't
> mean to
> > offend, really, or start another holy war ;)
> >
> > However, my experience with the mod_perl RPM from RH5.2 was not the
> > greatest. Others have had similar experiences to mine. It also
> appears,
> > from the comments today, that the 6.0 RPMs are working out of the box,
> which
> > is a good thing. I agree that having a working RPM at first is great,
> and
> > that compiling your own is a better way to learn various nuances.
> Actually,
> > if the RPM were fully tricked out, that would probably be best (libapreq
> and
> > all) so that when someone reads the eagle book and tries an exercise,
> they
> > aren't confused because a mod_perl part wasn't enabled.
> >
> > I don't think that we ought to be assuming that everyone has make, gcc,
> and
> > other such tools as standard equipment. As Linux rolls out into the
> > mainstream (more than it already is, that is) you can be less certain of
> > things like that. I think that my old 5.2 install had a development
> check
> > box during the custom install that I left unchecked, so make was not
> part of
> > my system initially. At the time, I was just messing around. When I
> > decided to get a little more serious about stuff, figuring out what was
> > missing was a chore.
> >
> > But hey, isn't the point of the Guide to provide info like that -
> getting
> > off the ground type of stuff? Given the discussion thus far, maybe a
> > section on RPMs is necessary, if just to dispel the rumors that mod_perl
> > RPMs are bad (you just need the right ones?) And I still think that,
> since
> > the Guide explains how to roll your own mod_perl, that the tools needed
> to
> > do it would help lots of folks.
> >
> > --Geoff
> >
> > > -----Original Message-----
> > > From: Stas Bekman [SMTP:[EMAIL PROTECTED]]
> > > Sent: Wednesday, October 06, 1999 8:31 AM
> > > To: David Harris
> > > Cc: Young, Geoffrey S.; mod_perl list
> > > Subject: Re: New mod_perl RPM really needed? (was: sourcegarden plug)
> > >
> > > > > Thus, it might be worth mentioning that RPMs are a _bad_
> idea for
> > > > > those just getting into mod_perl. That is, unless others have
> been
> > > more
> > > > > successful that I...
> > >
> > > RPMs aren't bad. You should understand something. RPMs and other
> packaging
> > > systems were developed to enable distributing many or single pieces of
> > > software, which will plug in and work the moment they are installed.
> RPMs
> > > also make it very easy to incorporate your own patches into a basic
> tar.gz
> > > of any sw. When you don't really understand how RPM works, and how to
> > > write SRPM (source RPMs), it's a black box for you. And when it
> doesn't
> > > work you blame the one who made this box for you.
> > >
> > > 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.
> > >
> > > 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
> > >
> > > And of course, you have all the development tools, this is something
> > > obvious (Am I wrong?), I'm not sure how can you run your own machine
> > > without having make and other tools. May be I'm too biased. Should we
> > > write a guide of how to compile a c program and where to get the tools
> > > from? I don't know may be we should...
> > >
> > > > A while ago in his "sourcegarden plug" thread Stas wrote:
> > > > > Jim, one of the "services" we _want_ to provide at mod_perl Source
> > > Garden
> > > > > (modperl.sourcegarden.org) is prebuilded mod_perl RPMs in its
> various
> > > > > configurations and for mainly used platforms. Taken that we are
> only a
> > > few
> > > > > folks who actually contributing to this project, this item is not
> on
> > > the
> > > > > top of our priorities.
> > > > >
> > > > > I wonder if you or someone else may want to step in, and to start
> > > creating
> > > > > correctly prebuilded SRPMs and RPMs, and if later feel that it's
> not
> > > > > challenging (which I've found quite challenging, YMMV), someone
> else
> > > will
> > > > > pick the falling flag. But it's definitely a good way to learn
> > > creating
> > > > > RPMs which are very usefull, contributing back to our community,
> (and
> > > > > fighting our mutual enemy :)
> > > >
> > > > I'm basically saying that I could do this and put together some
> > > mod_perl+Apache
> > > > and libapreq RPM's today.. but I'm just wondering if it's really
> needed.
> > >
> > > 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!
> > >
> > >
> _______________________________________________________________________
> > > 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
> >
>
>
>
> _______________________________________________________________________
> 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
