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