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