Re: FC4: modperl, CGI, and perl (problem)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2005-04-21 at 03:51 +0100, José Pedro Oliveira wrote:
> Warren Togami wrote:
> > José Pedro Oliveira wrote:
> > 
> >> 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.
> > 
> > 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)
> 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.

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.


[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Legacy Announce]     [Fedora PHP Devel]     [Kernel Devel]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Big List of Linux Books]     [Gimp]     [Yosemite Information]
  Powered by Linux