Re: a summary was: RE: New mod_perl RPM really needed? (was: sourcegarden plug)

[Dave Hodgkinson]

Stas Bekman <[EMAIL PROTECTED]> writes:

> 
> > On Wed, 06 Oct 1999, Stas Bekman wrote:
> > > 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!
> > 
> > Because most people's Apache's are a little more complex. (e.g. requiring
> > php or some other module). I suppose you could compile it in statically
> > _and_ allow DSO's, but then it's hard to nail down exactly what people want
> > (something I abhor about rpm's - there's no flexibility when you install
> > them).
> 
> Matt, we aren't trying to take away the joy of mod_perl building :)
> the RPM woes were about newbies installing mod_perl, grabbing the
> book and getting their feet wet with mod_perl in a matter of seconds. 
> 
> An EVERYTHING=1 + static mod_perl would be perfect for 99.9% of new users. 
> 
> The people whose Apaches are a little more complex, know how to build
> mod_perl from the sources, don't we :) 

Which reminds me of something I do here. Typically, when building the
bloated apache that sits behind squid or whatever, you need mod_perl,
php, mod_ssl and the rest. As you install each they typically crap
over each other's config.status files. So I save them after each step
and then build and squirrel away the loaded config.status file.

A trivial tip, but one that newbies might find useful. If Stas hasn't
already got it in his book ;-)

-- 
David Hodgkinson, Technical Director, Sift PLChttp://www.sift.co.uk
Editor, "The Highway Star"   http://www.deep-purple.com
Dave endorses Yanagisawa saxes, Apache, Perl, Linux, MySQL, emacs, gnus

Re: New mod_perl RPM really needed? (was: sourcegarden plug)

[Stephen Peters]

Stas Bekman <[EMAIL PROTECTED]> writes:

> 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!

I found one, actually.  On my RH6.0 box at home, I installed an
apache+mod_perl SRPM that seemed to work fine.  Mod_perl was
statically linked in, so I don't have the chaining difficulties.
Unfortunately, I had to compile from the SRPM version, since the RPM
was compiled for RH5.2, and was therefore looking under the wrong Perl
version number for Perl modules.

If you look on any RedHat mirror which has the contrib directory, you
should be able to find an apache_mod-perl RPM and SRPM.

-- 
Stephen L. Peters   [EMAIL PROTECTED]
  PGP fingerprint: BFA4 D0CF 8925 08AE  0CA5 CCDD 343D 6AC6
 "Poodle: The other white meat." -- Sherman, Sherman's Lagoon

Re: New mod_perl RPM really needed? (was: sourcegarden plug)

[Jauder Ho]

If anyone really cares, I have a mod_perl rpm built at
http://www.carumba.com/rpms/. It really is not that hard to do. Solaris
packaging is much more of a pain in the butt.

--Jauder

On Wed, 6 Oct 1999, David Harris wrote:

> 
> Young, Geoffrey S wrote:
> > 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...
> 
> I've got mod_perl running just fine with my own Apache package and RedHat's
> mod_perl RPM. I understand that this keeps me from being able to use some stuff
> like request chaining, but I've not had a need for it. I've also stayed away
> from any mod_perl development environments (Embperl, Mason, whatver) and just
> wrote the handlers all myself.
> 
> I'm going to package all of my work up today into RPMS and publish them out to
> the production servers, so I'm wondering if I should make my own mod_perl and
> Apache RPM or stick with what I have working. I keep hearing that RPM's and
> mod_perl are evil, but personally everything installed and worked without a
> hitch.
> 
> Oh, I remember that I had some trouble compiling libapreq, but copying a few
> mod_perl header files into the system solved that without too much pain.
> 
> 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.
> 
>  - David Harris
>Principal Engineer, DRH Internet Services
> 
> 
> 

Re: New mod_perl RPM really needed? (was: sourcegarden plug)

[Jim Winstead]

On Oct 06, David Harris wrote:
> Young, Geoffrey S wrote:
> > 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...
> 
> I've got mod_perl running just fine with my own Apache package and RedHat's
> mod_perl RPM. I understand that this keeps me from being able to use some stuff
> like request chaining, but I've not had a need for it. I've also stayed away
> from any mod_perl development environments (Embperl, Mason, whatver) and just
> wrote the handlers all myself.
> 
> I'm going to package all of my work up today into RPMS and publish them out to
> the production servers, so I'm wondering if I should make my own mod_perl and
> Apache RPM or stick with what I have working. I keep hearing that RPM's and
> mod_perl are evil, but personally everything installed and worked without a
> hitch.
> 
> Oh, I remember that I had some trouble compiling libapreq, but copying a few
> mod_perl header files into the system solved that without too much pain.

I'll second these experiences almost exactly (down to the problems
with libapreq, which is where this thread started :).

I upgraded about 40 machines from mod_perl-1.19 to mod_perl-1.21
two days ago via RPM, and it went flawlessly. (And took only a few
minutes since it was just done as one batch process.)

I think the bottom line is that you should know your own environment.
Some people seem to think anything involving RPMs precludes that. For
some people, it may, but I hate to see blanket statements like "don't
use RPM". A more apropros one might be "don't do anything you don't
understand".

Jim

a summary was: RE: New mod_perl RPM really needed? (was: sourcegarden plug)

[Stas Bekman]

> On Wed, 06 Oct 1999, Stas Bekman wrote:
> > 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!
> 
> Because most people's Apache's are a little more complex. (e.g. requiring
> php or some other module). I suppose you could compile it in statically
> _and_ allow DSO's, but then it's hard to nail down exactly what people want
> (something I abhor about rpm's - there's no flexibility when you install
> them).

Matt, we aren't trying to take away the joy of mod_perl building :)
the RPM woes were about newbies installing mod_perl, grabbing the
book and getting their feet wet with mod_perl in a matter of seconds. 

An EVERYTHING=1 + static mod_perl would be perfect for 99.9% of new users. 

The people whose Apaches are a little more complex, know how to build
mod_perl from the sources, don't we :) 

I guess this topic has been exhausted.

A summary:

David Harris has kindly suggested to work on a cool apache+mod_perl SRPM,
and once he make it, we all hope that there will be no more RPMs woes. If
there will be, a URL of the David's masterpiece would make the answer
simple and short. The SRPM will be available from either perl.apache.org
or modperl.sourcegarden.org.

Young, Geoffrey S has kindly volunteered to gather up the problematic
issues with RH's RPMs and their solution, which will enter the guide, the
moment they will be ready.

Thank you all for contributing to this thread. 

___
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-+ = singlesheavenhttp://www.singlesheaven.com

RE: New mod_perl RPM really needed? (was: sourcegarden plug)

[David Harris]

Stephen Peters [mailto:[EMAIL PROTECTED]] wrote:
> I found one, actually.  On my RH6.0 box at home, I installed an
> apache+mod_perl SRPM that seemed to work fine.  Mod_perl was
> statically linked in, so I don't have the chaining difficulties.
> Unfortunately, I had to compile from the SRPM version, since the RPM
> was compiled for RH5.2, and was therefore looking under the wrong Perl
> version number for Perl modules.
>
> If you look on any RedHat mirror which has the contrib directory, you
> should be able to find an apache_mod-perl RPM and SRPM.

Found it...

Summary at:
http://www.rpmfind.net/linux/RPM/contrib/libc6/i386/apache_modperl-1.3.6-1.19-1
.i386.html

(S)RPMs:
ftp://rufus.w3.org/linux/contrib/libc6/SRPMS/apache_modperl-1.3.6-1.19-1.src.rp
m
ftp://rufus.w3.org/linux/contrib/libc6/i386/apache_modperl-1.3.6-1.19-1.i386.rp
m
ftp://rufus.w3.org/linux/contrib/libc6/i386/apache_modperl-devel-1.3.6-1.19-1.i
386.rpm

This looks good except for the fact that it is actually a replacement for the
apache package. I want something that will install alongside the apache package
and use the same DSO's and docs files, so that I can run multiple mod_perl and
non-mod_perl servers on the same machine.

Anyway, this package looks like a good starting point for making my own RPM.
I'll keep you all updated

 - David Harris
   Principal Engineer, DRH Internet Services

RE: New mod_perl RPM really needed? (was: sourcegarden plug)

[Matt Sergeant]

On Wed, 06 Oct 1999, Stas Bekman wrote:
> 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!

Because most people's Apache's are a little more complex. (e.g. requiring
php or some other module). I suppose you could compile it in statically
_and_ allow DSO's, but then it's hard to nail down exactly what people want
(something I abhor about rpm's - there's no flexibility when you install
them).

--


Details: FastNet Software Ltd - XML, Perl, Databases.
Tagline: High Performance Web Solutions
Web Sites: http://come.to/fastnet http://sergeant.org
Available for Consultancy, Contracts and Training.

RE: New mod_perl RPM really needed? (was: sourcegarden plug)

[Young, Geoffrey S.]

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
> > > 

RE: New mod_perl RPM really needed? (was: sourcegarden plug)

[Stas Bekman]

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 

RE: New mod_perl RPM really needed? (was: sourcegarden plug)

[Stas Bekman]

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-+ = singlesheavenhttp://www.singlesheaven.com

RE: New mod_perl RPM really needed? (was: sourcegarden plug)

[Young, Geoffrey S.]

Now, that's a good idea...

> -Original Message-
> From: David Harris [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, October 06, 1999 9:01 AM
> To:   Stas Bekman
> Cc:   Young, Geoffrey S.; mod_perl list
> Subject:      RE: New mod_perl RPM really needed? (was: sourcegarden plug)
> 
> 
> 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
> 

RE: New mod_perl RPM really needed? (was: sourcegarden plug)

[David Harris]

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

RE: New mod_perl RPM really needed? (was: sourcegarden plug)

[Young, Geoffrey S.]

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 

Re: New mod_perl RPM really needed? (was: sourcegarden plug)

[Stas Bekman]

> > 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-+ = singlesheavenhttp://www.singlesheaven.com