Bug 158354

Created attachment 114651 [details]
mod_perl specfile update

Can this be released as a Fedora Core 4 errata?

http://people.redhat.com/wtogami/temp/mod_perl/
Joe Orton built binaries of this and I copied them here for testing.  Please
find people who actually use mod_perl to test this.

The requirements need to be updated:
1) httpd >= 2.0.47   (README and Makefile.PL file)
2) add perl >=  3:5.8.6-14 (for CGI.pm 3.10)

See mod_perl specfile patch in comment #2.

Correction: patch in comment #1.

I can help test on Monday.

Anyway, I don't really like the suggested "perl >= 3:5.8.6-14 (for CGI.pm 3.10)"
dependency.  mod_perl does not need _any version_ of CGI.pm nor does it require
Perl >= 5.8.6 as such.  For example, I have a huge mod_perl app at work that,
well, is a real mod_perl app, it does not use CGI.pm for anything.

FC4 users will have a version of Perl installed that will satisfy the above
dependency anyway, so "hardcoding" it will just make life slightly harder for
example for folks who want to rebuild this locally on FC3.

On the other hand, the bump in the versioned httpd dependency looks ok.

I am removing the new perl versioned dependency from -3.

Requires:       httpd-mmn = %([ -a %{_includedir}/httpd/.mmn ] && cat
%{_includedir}/httpd/.mmn || echo missing)

On second thought, isn't this adequate for a httpd dependency?  The mmn number
is supposed to be something about binary compatibilit with modules?

AFAICS yep, from httpd changelog:

* Tue Sep 03 2002 Joe Orton <jorton> 2.0.40-6
- provide "httpd-mmn" to manage module ABI compatibility

The versioned httpd build dep is good and should stay, though.

(In reply to comment #6)
> ...
> Anyway, I don't really like the suggested "perl >= 3:5.8.6-14 (for CGI.pm 3.10)"
> dependency.  mod_perl does not need _any version_ of CGI.pm nor does it require
> Perl >= 5.8.6 as such.  For example, I have a huge mod_perl app at work that,
> well, is a real mod_perl app, it does not use CGI.pm for anything.
> 
> FC4 users will have a version of Perl installed that will satisfy the above
> dependency anyway, so "hardcoding" it will just make life slightly harder for
> example for folks who want to rebuild this locally on FC3.
> ...

That's exactly why the perl dependency should be there.  It would require ppl
building mod_perl in FC3 (and RHEL4, ...) to read the mod_perl and perl packages
changelogs before sucessfully installing it in ther distro.  They would be
warned that CGI.pm 3.10 comes _highly_ recommended.

Yes, it is always recommended to read the changelogs and docs but no, NOT
required to rebuild or upgrade their Perl because of this.  People who upgrade
from mod_perl 1.99_xx to 2.0.0 (no matter on which distro version) without
reading the docs are most likely in for a few nasty surprises anyway.

Le me repeat, mod_perl does not need CGI.pm _at all_.  An app that uses CGI.pm
and wants to run under mod_perl should set its required versions appropriately,
in its Perl code or rpm deps.  It is not the business of the mod_perl package to
inflict this on everyone.

[mod_perl-devel] Multilib regressions for
/ppc/mod_perl-devel/usr/include/httpd/modperl_xs_sv_convert.h
This means the .h file was identical in the old pacakge between ppc and ppc64,
but now no longer is.

[BAD] [mod_perl] usr/lib/httpd/modules/mod_perl.so lost -DFORTIFY_SOURCE on i386 
Build logs show "-O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m32
-march=i386 -mtune=pentium4 -fasynchronous-unwind-tables" so there is some other
cause for losing fortify source.  -O0 of perl-DBD-Pg caused this, but this is
some other issue.  Another possible cause is if all static buffers became dynamic.

Both of these issues need to be investigated and fixed before the FC4 update is
issued.

Warren,

Just rebuild mod_perl-2.0.0 in a i386 FC4test3+rawhide system without seeing the
FORTIFY_SOURCE warn/error messages.

RPMS: kernel-2.6.11-1.1340_FC4,  rpm-4.4.1-20,  gcc-4.0.0-8,  perl-5.8.6-15

The only "strange" thing may be using -fpic and -fPIC at the same time. Can
-fpic be safely dropped from the specfile (CFLAGS and OPTIMIZE) ?  

mod_perl 2.0.1 is already available for download in CPAN mirrors.

Announcement:
http://marc.theaimsgroup.com/?l=apache-modperl&m=111904793818463&w=2

CPAN:
http://search.cpan.org/dist/mod_perl/
http://search.cpan.org/~gozer/mod_perl-2.0.1/Changes

/usr/lib/httpd/modules/mod_perl.so lost -DFORTIFY_SOURCE

Rebuilt with 2.0.1, and it still lost FORTIFY_SOURCE.  Should we be concerned
about this?

http://people.redhat.com/wtogami/temp/mod_perl/
Somebody please verify these binaries before pushing to FC4 updates.

Just a quick not that I've made FC3 rpm's from what Warren released. Only line
changed was in the .spec file referrencing FC4 and was just changed to FC3.

I've had no problems with these RPM's, so I'm proposing that they get included
in the FC3 updates as well.

--Greg

Pushing this to FC3 would be less trivial than FC4 due to CGI.pm stuff:  
https://www.redhat.com/archives/fedora-perl-devel-list/2005-June/msg00025.html  

Because of the API changes in mod_perl 2.0 it can't be issued as an FC3 update
at all; that would break existing sites horribly.  For FC4 it's fine of course.

Did anybody actually test the binaries in Comment #17?  I will not push it until
somebody gives thumbs up.

(In reply to comment #21)
>
> Did anybody actually test the binaries in Comment #17?  I will not push it until
> somebody gives thumbs up.

I've installed  the fc4 i386 rpm.
No problems installing and what little I've done with it works fine.

FC4 update issued.