Warren,
We have another major problem with mod_perl 2.0.0 RC5 as it also requires CGI.pm version 3.08 which has just hit CPAN today (a couple of hours ago). CGI.pm is one of the perl modules affected by the module rename (Apache:: -> Apache2::) done in mod_perl RC5.
Problem: How to package CGI 3.08? CGI.pm is a dual life perl module: shipped with perl and also shipped as an independent module .
Possible solutions: 1) patching perl-5.8.6 2) remove CGI from the core perl package and and go back to perl-CGI as it was done in Red Hat 7.3, 8, and 9 3) wait for perl-5.8.7 and hope that it includes CGI 3.08.
Option 3 is rather optimistic. Even if perl-5.8.7 is released next week, it will probably be to late to include it in FC4.
Option 1 or option 2?
Right now I would go for option 2. It will be easier to release updates if something is still broken.
Comments?
[Warren: is there any change of updating perl after test3 if it doesn't break anything?]
Regards, jpo
PS - Joe Orton knows about this problem. One of the mails in the mod_perl mailing list was his.
References: [1] mod_perl 2.0 renaming http://perl.apache.org/docs/2.0/rename.html [2] Lincoln D. Stein > CGI.pm http://search.cpan.org/dist/CGI.pm/
José Pedro Oliveira wrote:
Warren,
We have another major problem with mod_perl 2.0.0 RC5 as it also requires CGI.pm version 3.08 which has just hit CPAN today (a couple of hours ago). CGI.pm is one of the perl modules affected by the module rename (Apache:: -> Apache2::) done in mod_perl RC5.
Problem: How to package CGI 3.08? CGI.pm is a dual life perl module: shipped with perl and also shipped as an independent module .
Possible solutions:
- patching perl-5.8.6
- remove CGI from the core perl package and and go back to perl-CGI as it was done in Red Hat 7.3, 8, and 9
- wait for perl-5.8.7 and hope that it includes CGI 3.08.
If perl-5.8.7 will include CGI 3.08, then adding a perl-CGI package now would be a hassle because it is a temporary situation. To make matters worse the existing perl packages contain "Obsoletes: perl-CGI" which may cause problems for us. For these reasons it may be better to patch perl-5.8.6. Short-term ugliness for simpler long term maintenance?
Maybe my opinion here is totally wrong, so I would wait for Ville to choose between #1 or #2.
How large would a patch for solution #1 be?
Warren Togami wtogami@redhat.com
Warren Togami wrote:
José Pedro Oliveira wrote:
Warren,
We have another major problem with mod_perl 2.0.0 RC5 as it also requires CGI.pm version 3.08 which has just hit CPAN today (a couple of hours ago). CGI.pm is one of the perl modules affected by the module rename (Apache:: -> Apache2::) done in mod_perl RC5.
Problem: How to package CGI 3.08? CGI.pm is a dual life perl module: shipped with perl and also shipped as an independent module .
Possible solutions:
- patching perl-5.8.6
- remove CGI from the core perl package and and go back to perl-CGI as it was done in Red Hat 7.3, 8, and 9
- wait for perl-5.8.7 and hope that it includes CGI 3.08.
If perl-5.8.7 will include CGI 3.08, then adding a perl-CGI package now would be a hassle because it is a temporary situation. To make matters worse the existing perl packages contain "Obsoletes: perl-CGI" which may cause problems for us. For these reasons it may be better to patch perl-5.8.6. Short-term ugliness for simpler long term maintenance?
Maybe my opinion here is totally wrong, so I would wait for Ville to choose between #1 or #2.
How large would a patch for solution #1 be?
Perl-5.8.6 ships with CGI.pm 3.05. Mod_perl 2.0.0 RC5 requires CGI.pm 3.08.
Patches in unified format (3.05 -> 3.08) 1) Full patch is around 141 KB. 2) If we exclude the docs (README, Changes, and cgi_docs.html) we can reduce the patch to 89 KB.
Note: the CGI documentation files aren't ship with perl.
Source files: 4e1e2288369089e56e8a115aade93ea4 CGI.pm-3.05.tar.gz 6f13f09e498cacd37ceb271443269b8d CGI.pm-3.08.tar.gz
jpo
On Thu, 2005-04-21 at 03:51 +0100, José Pedro Oliveira wrote:
Warren Togami wrote:
José Pedro Oliveira wrote:
Possible solutions:
- patching perl-5.8.6
- remove CGI from the core perl package and and go back to perl-CGI as it was done in Red Hat 7.3, 8, and 9
- wait for perl-5.8.7 and hope that it includes CGI 3.08.
If perl-5.8.7 will include CGI 3.08, then adding a perl-CGI package now would be a hassle because it is a temporary situation. To make matters worse the existing perl packages contain "Obsoletes: perl-CGI" which may cause problems for us. For these reasons it may be better to patch perl-5.8.6. Short-term ugliness for simpler long term maintenance?
Maybe my opinion here is totally wrong, so I would wait for Ville to choose between #1 or #2.
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.
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.
How large would a patch for solution #1 be?
Perl-5.8.6 ships with CGI.pm 3.05. Mod_perl 2.0.0 RC5 requires CGI.pm 3.08.
Patches in unified format (3.05 -> 3.08)
- Full patch is around 141 KB.
- If we exclude the docs (README, Changes, and cgi_docs.html) we can reduce the patch to 89 KB.
If the patch upgrade will be to the full 3.08, I don't think implementing it as a patch file adds much value. Just bundle the full updated CGI modules in the SRPM and copy into place during build.
The "patch only necessary bits" approach would result in something like: http://search.cpan.org/diff?from=CGI.pm-3.07&to=CGI.pm-3.08 The 3.05->3.07 diff would need to be checked for related bits too.
No strong opinions between these three approaches. Perhaps leaning slightly towards the full patch option at the moment.
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@redhat.com
Warren Togami wrote:
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.
Someone going to supply the patch for FC4's perl-5.8.6? We really shouldn't ship test3 with broken mod_perl.
Warren
Warren Togami wrote:
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.
Someone going to supply the patch for FC4's perl-5.8.6? We really shouldn't ship test3 with broken mod_perl.
Patches in bugzilla entry #155839.
Bug 155839 perl: CGI update to version 3.08 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155839
If someone could review them would be great. Perl builds and passes CGI tests without problems. Didn't had time to test mod_perl CGI apps.
Regards, jpo
José Pedro Oliveira wrote:
[Warren: is there any change of updating perl after test3 if it doesn't break anything?]
Highly unlikely. Even if we can prove with a test-tree that it breaks nothing and fixes several bugs, the choice is up to Sopwith. We can't make those kinds of guarantees today because perl-5.8.7 isn't released.
Warren Togami wtogami@redhat.com
perl-devel@lists.fedoraproject.org
-
Jose Pedro Oliveira -
Ville Skyttä -
Warren Togami