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(a)redhat.com