FC4: modperl, CGI, and perl (problem)

Warren Togami wtogami at redhat.com
Thu Apr 21 21:57:17 UTC 2005


Ville Skyttä wrote:
> 
> I think it's better to wait first if 5.8.7 makes it in time for FC-4,
> and if it contains CGI 3.08.  If not, both #1 and #2 have their
> advantages and disadvantages, and #1 can be split into "patch only as
> much as necessary to make it work with the new mod_perl", or do a full
> update to 3.08 in it.

Just talked to Sopwith and notting.  perl-5.8.7 after test3 is not going 
to be possible.

Can you magically make perl-5.8.7 happen upstream by Saturday, and have 
everything tested by Monday for inclusion?  Otherwise it is impossible.

> 
> The separation could cause a chicken-egg bootstrap problem.  To be on
> the safe side, the perl package should have "Requires: perl-CGI >=
> 3.05".  But the perl package is also a build dependency for the now
> separated perl-CGI... of course, it is possible to cheat around this by
> using the old perl package to build the new CGI first, then build a new
> perl that requires the separated CGI.  But as said that would be
> cheating.
> 
> Another approach in the separation would be to not have the Requires:
> perl-CGI in perl.  That would break the dependecies for packages that
> just assume CGI being present if perl is, instead of containing an
> explicit (possibly autogenerated) dependency on perl(CGI).
> 
> Regarding the Obsoletes:, all of those should really be made versioned
> in the perl specfile.  That version needs to be bumped on every upstream
> Perl release as necessary -> more maintenance, although not _that_ much.
> Adding versioned Provides: for these would be nice too.

Sopwith prefers the patching solution.  While ugly it causes the fewest 
problems for us.

Please open a new bug and submit the patch.  This will at least 
guarantee that mod_perl works in FC4.

Warren Togami
wtogami at redhat.com




More information about the perl-devel mailing list