Bug 166063

HTML::Mason 1.31 was released today and is available on CPAN.  It contains a
handful of bug fixes.  Might be worth upgrading prior to a review.

Will do.

NEEDSWORK:

* nitpicks:
- %check || :, please use "%check".
- sed'ing LD_RUN_PATH, please remove
- setting perl_vendorlib is superfluous with FC >= FC3.

* Arguable/Discussable:
- /var/www/mason and /var/www/comp
I am not sure if these are clever choices. /var/www/mason seems reasonable to
me, but /var/www/comp seems a bit too unspecific to me. However I don't have
strong opinion on this.

* Major issue:
Your /etc/http.d/conf.d/perl-HTML-Mason.conf doesn't work on FC4.
It prevents apache/httpd from startup:

# service http start
Starting httpd:                                            [FAILED]
[Sun Aug 21 07:34:47 2005] [error] Can't load Perl module Apache2 for server
..., exiting..

I am not as much an apache expert to be able to tell what is wrong with it.
AFAIS, it definitely is related to these lines in perl-HTML-Mason.conf, which
would indicate a mod_perl/mod_perl2 incompatiblity issue:
PerlModule Apache2
PerlModule Apache::compat

(In reply to comment #3)
[snip]
> - /var/www/mason and /var/www/comp
> I am not sure if these are clever choices. /var/www/mason seems reasonable to
> me, but /var/www/comp seems a bit too unspecific to me. However I don't have
> strong opinion on this.

My (unrequested) opinion would be to do what conf.d/perl.conf does and leave
every option commented as examples of what could be done.  For example, I use
/var/cache/mason (like mod_proxy) for MasonDataDir and /var/www/mason as
MasonCompRoot.  Also, since libapreq2 is available in extras, an example of
using the apache args method would be nice in addition to the cgi args method.

[snip]
> I am not as much an apache expert to be able to tell what is wrong with it.
> AFAIS, it definitely is related to these lines in perl-HTML-Mason.conf, which
> would indicate a mod_perl/mod_perl2 incompatiblity issue:
> PerlModule Apache2
> PerlModule Apache::compat

Neither of these lines are used with current versions of mod_perl and
HTML::Mason.  A physical Apache2 module was removed in mod_perl 2.0.0rc5, and
Apache::compat isn't needed in HTML::Mason >= 1.30.

(In reply to comment #4)
> (In reply to comment #3)
> [snip]
> My (unrequested) opinion would be to do what conf.d/perl.conf does and leave
> every option commented as examples of what could be done.  For example, I use
> /var/cache/mason (like mod_proxy) for MasonDataDir and /var/www/mason as
> MasonCompRoot.
Agreed, /var/cache/mason seems to be a better choice to me.

Sorry, I rushed this one out.  I'll be more careful in the future.

I still haven't tested this well, but httpd will at least start with this:

 http://ftp.kspei.com/pub/steve/rpms/perl-HTML-Mason-1.31-2.src.rpm
 http://ftp.kspei.com/pub/steve/rpms/perl-HTML-Mason/perl-HTML-Mason.spec

The sample config file definitely still could use some work, so suggestions on
that are welcome.  (I see I missed a couple of things in comment #4.)

Let's try this again...

 http://ftp.kspei.com/pub/steve/rpms/perl-HTML-Mason-1.31-3.src.rpm
 http://ftp.kspei.com/pub/steve/rpms/perl-HTML-Mason/perl-HTML-Mason.spec

Created attachment 118085 [details]
Sample Mason configuration for the conf.d directory.

Here's my stab at a Mason configuration file for Apache 2.0.x.	It's based on
what I've been using in a production environment for some time.

It should be enough to get Mason up and running with basic functionality, and
I've included a pointer to the full list of configuration options.

Created attachment 118164 [details]
Update to 1.3101 and requirments cleanup

Steven,

Could you update HTML::Mason to version 1.3101 and clean the requirements and
build requirements list (patch attached)?

The following requirments are all core perl modules (perl > 5.8.0) [1]
  BuildRequires:  perl(CGI) >= 2.46
  BuildRequires:  perl(File::Spec) >= 0.8
  BuildRequires:  perl(Scalar::Util) >= 1.01
  BuildRequires:  perl(Test)
  BuildRequires:  perl(Test::Builder)
  Requires:	  perl(CGI) >= 2.46
  Requires:	  perl(File::Spec) >= 0.8
  Requires:	  perl(Scalar::Util) >= 1.01

References:
[1] Source: script corelist from perl-Module-CoreList

How does this look?

http://ftp.kspei.com/pub/steve/rpms/perl-HTML-Mason-1.3101-1.src.rpm
http://ftp.kspei.com/pub/steve/rpms/perl-HTML-Mason/perl-HTML-Mason.spec

%changelog
* Mon Aug 29 2005 Steven Pritchard <steve> 1.3101-1
- Update to 1.3101
- Spec cleanup (jpo)
- Include sample config file from Chris Grau

Created attachment 118655 [details]
Specfile patch: adds documentation, ...

Changelog:
* adds the html documentation pages
* adds the samples
  (the eg/ appliaction brings a new requirement which is filtered)
* changes the mason dir from /var/www/mason/html to /var/www/mason
* changes the "perl Makefile.PL" statement

Do we have consensus on how to continue?

What I can tell: Steve's rpm perl-HTML-Mason-1.3101-1.src.rpm works fine with
rt3 under FC4 ;)

Did anybody test this under FC3?

I'd approve it for FC4 and FC5, if we have consensus on the mason dirs 
(FWIW: Debian seems to use /var/cache/mason).

+# Requires: filter perl(MasonX::Request::PlusApacheSession)
+cat <<__EOF__ > %{name}-perlreq
+#!/bin/sh
+/usr/lib/rpm/perl.req \$* | grep -v 'perl(MasonX::Request::PlusApacheSession)'
+__EOF__
+%define __perl_requires %{_builddir}/HTML-Mason-%{version}/%{name}-perlreq
+chmod +x %{__perl_requires}

Is this really necessary?  I don't see this dependency.

-echo '!' | %{__perl} Makefile.PL INSTALLDIRS=vendor
+%{__perl} Makefile.PL INSTALLDIRS=vendor

Interesting...  That must have changed since the last build I did by hand.

Fixed.
 
-mkdir -p $RPM_BUILD_ROOT%{_localstatedir}/www/mason/html
+mkdir -p $RPM_BUILD_ROOT%{_localstatedir}/www/mason

Shouldn't DocumentRoot (/var/www/mason/html) be under MasonCompRoot
(/var/www/mason)?  I see that's not what the config file I'm including does now.
 My old one did...

I'll change it, but I'm still curious.  :-)
 
+%doc htdocs/ eg/ samples/
-%{_localstatedir}/www/mason/
+%dir %{_localstatedir}/www/mason

Done.

http://ftp.kspei.com/pub/steve/rpms/perl-HTML-Mason-1.3101-2.src.rpm
http://ftp.kspei.com/pub/steve/rpms/perl-HTML-Mason/perl-HTML-Mason.spec

(In reply to comment #14)
> +# Requires: filter perl(MasonX::Request::PlusApacheSession)
> +cat <<__EOF__ > %{name}-perlreq
> +#!/bin/sh
> +/usr/lib/rpm/perl.req \$* | grep -v 'perl(MasonX::Request::PlusApacheSession)'
> +__EOF__
> +%define __perl_requires %{_builddir}/HTML-Mason-%{version}/%{name}-perlreq
> +chmod +x %{__perl_requires}
> 
> Is this really necessary?  I don't see this dependency.

I seem to recall that perl(MasonX::Request::PlusApacheSession) gets pulled in by
one of the examples.  I had to do something like this with an older custom
package of HTML::Mason.

> -mkdir -p $RPM_BUILD_ROOT%{_localstatedir}/www/mason/html
> +mkdir -p $RPM_BUILD_ROOT%{_localstatedir}/www/mason
> 
> Shouldn't DocumentRoot (/var/www/mason/html) be under MasonCompRoot
> (/var/www/mason)?  I see that's not what the config file I'm including does now.

When I set up a Mason site, I usually use /var/www/html as the document root and
/var/www/mason as the private component root.  YMMV, of course.

Yeah, the examples introduce new provides and requires.  I'm fixing that now. 
(I noticed right after I hit "Save Changes".  Oops.)

http://ftp.kspei.com/pub/steve/rpms/perl-HTML-Mason-1.3101-3.src.rpm filters out
the bogus requires and provides.

Steven,

Can you replace the perl(mod_perl2) BR and R by mod_perl only?

This way perl-HTML-Mason will work for FC-3 and FC-4. Otherwise it will only
work with FC-4 (perl(mod_perl2) is only provided by mod_perl >= 2.0.0 RC5).

/jpo

Hum!  Please ignore my last comment.  I don't know if it is possible to support
mod_perl 1.99 (judging ny the comments in ApacheHandler.pm).  

I'm going to attempt to support FC-3, but I'd rather not worry about it until
after we get this into CVS.  Initially I'll only request builds for FC-4 and devel.

(In reply to comment #20)
> I'm going to attempt to support FC-3, but I'd rather not worry about it until
> after we get this into CVS.  Initially I'll only request builds for FC-4 and
devel.

I'd have to look at the code to be sure, but I think Mason went the same route
as other modules that depend on mod_perl.  Mason won't work with anything before
mod_perl 2.0.0rc5 and thus it won't work on FC-3.

If we really want Mason on FC-3, I think someone should package up 1.28.  Either
that version or one of the 1.29 dev releases supported mod_perl 1.99.

I have nothing further to add. Publish++ (FC-4 and devel)

I am still having doubts on /var/www/mason and therefore don't want to approve
the package (Did anybody consider the FHS?).

As JPO seems to be convinced, I am assigning this package request to him.

(In reply to comment #23)
> I am still having doubts on /var/www/mason and therefore don't want to approve
> the package (Did anybody consider the FHS?).

I think if we were to follow the FHS, the entire www tree would be moved to
/srv.  However, I'm sure that's a flame war that's been faught elsewhere.

The /var/www/mason directory is not without precedent.  Consider, for example,
/var/www/{cgi-bin,error,icons,manual} owned by httpd and httpd-manual.  Also
/var/www/usage owned by webalizer.  Granted, all of these are usually aliased to
public URLs, but I think the real point is to prevent them from interfering with
the document root.

I don't know how others go about this, but my use of /var/www/mason is as a
private component root so that components/pages in the document root can call
them, but they are not accessible through a public URL.

(In reply to comment #24)
> (In reply to comment #23)
> > I am still having doubts on /var/www/mason and therefore don't want to approve
> > the package (Did anybody consider the FHS?).
> 
> I think if we were to follow the FHS, the entire www tree would be moved to
> /srv.  However, I'm sure that's a flame war that's been faught elsewhere.
Yes, but you are aware, that the move to /srv already is taking place, even on
RH based distributions?

> The /var/www/mason directory is not without precedent.  Consider, for example,
> /var/www/{cgi-bin,error,icons,manual} owned by httpd and httpd-manual.  Also
> /var/www/usage owned by webalizer. 

> I don't know how others go about this, but my use of /var/www/mason is as a
> private component root so that components/pages in the document root can call
> them, but they are not accessible through a public URL.
Let me ask differently: Can /var/www/mason be read-only?

(In reply to comment #25)
> (In reply to comment #24)
> > (In reply to comment #23)
> > > I am still having doubts on /var/www/mason and therefore don't want to approve
> > > the package (Did anybody consider the FHS?).
> > 
> > I think if we were to follow the FHS, the entire www tree would be moved to
> > /srv.  However, I'm sure that's a flame war that's been faught elsewhere.
> Yes, but you are aware, that the move to /srv already is taking place, even on
> RH based distributions?

No, I was not aware.  Glad to hear it.  I wonder how long it will take me to get
used to typing /srv instead of /var.

> > The /var/www/mason directory is not without precedent.  Consider, for example,
> > /var/www/{cgi-bin,error,icons,manual} owned by httpd and httpd-manual.  Also
> > /var/www/usage owned by webalizer. 
> 
> > I don't know how others go about this, but my use of /var/www/mason is as a
> > private component root so that components/pages in the document root can call
> > them, but they are not accessible through a public URL.
> Let me ask differently: Can /var/www/mason be read-only?

If, after developing some code and installing it on a production system, the
admin chooses to make /var/www/mason read-only, everything will still work. 
Mason writes its cache files to MasonCacheDir, which we are pushing as
/var/cache/mason in this package.

I hope I understood correctly what you were asking here.

Just happened to notice that the summary of this package could be improved 
somewhat, for example: 
 
Summary: Powerful Perl-based web site development and delivery engine 

I've updated the summary.

(In reply to comment #26)

> > Let me ask differently: Can /var/www/mason be read-only?
> 
> If, after developing some code and installing it on a production system, the
> admin chooses to make /var/www/mason read-only, everything will still work. 
> Mason writes its cache files to MasonCacheDir, which we are pushing as
> /var/cache/mason in this package.
> 
> I hope I understood correctly what you were asking here.
Yes, this is what I meant, because IMO, it would not be a good idea to have
dynamically changing files under /var/www.

Housekeeping - Package has already been released