Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Merge Review: php-pear Alias: php-pear https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226295 ------- Additional Comments From rpm@xxxxxxxxxx 2007-02-06 14:39 EST ------- OK some comments from me (numbering not related to numbering in above bugs): 1. Chris, I'm not sure what your proposal re: splitting the "PEAR class" from the "PEAR installer" is. Are you referring specifically to the file PEAR.php? If so, whilst it's true that: a) looking at CVS this hasn't changed for a while b) the PEAR and PEAR_Error classes contained within it are often required by other PEAR classes, I'm not sure that it makes any sense to split this one file off and do something separate with it. The distinction is not made upstream, so we shouldn't make it. (If you think there's justification upstream, please file a bug there). In any case, the PEAR installer requires the PEAR class, so we wouldn't gain anything useful that I can see. The PEAR command line installer is an intrinsic part of the PEAR package and uses most of the files from it; it is not a distinct "binary". 2) I disagree with your assertion that the PEAR installer is not updated frequently. Most of the "PEAR package" is related to the PEAR installer. For example, PEAR 1.5.0 fixes some critical bugs related to installing certain packages and the entire point of bug #173810 was to split this away from the PHP release cycle so that we can upgrade the PEAR installer in Fedora without having to wait for the next upstream PHP release. 3) I agree with the principle of splitting sub-packages out, particularly XML_RPC. However, this requires that we get a better bootstrapping method. I do not consider reverting to the PHP-release-lockin a better method. The best example of an alternative method which supports sub-packages without locking PEAR to PHP releases is over at PLD (similar method used by Mandriva): http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SPECS/php-pear-PEAR.spec This was discussed last year. Joe objected (I can't find a reference; it may have been in an offline discussion) to this method on the basis that it requires too much intimate knowledge of PEAR. I think that point is a fair one, although personally I think the above (PLD) method may be the lesser of two evils, which has the bonus of eliminating the PHAR problem. However, since Joe has been the maintainer of the php-pear package I have deferred to his judgement. That said, I do think now is an appropriate time to revisit this issue. Re: the PHAR bootstrapping: CS> The bootstrapping method uses a source file which changes at every single CS> release, there is no way for someone to download an old version of the CS> bootstrap code. This does indeed suck but is a problem upstream which, if fixed, would negate this point. However my personal preferred bootstrap method would be the PLD one, which would also eliminate this problem, since that is based on the standard released PEAR tarball (i.e. PEAR-x.y.z.tgz) and therefore benefits from all the normal PEAR package release mechanism (archived versions, changelog, no special treatment required to keep it up to date) with the added bonuses that - it is readable with standard tools - it backports more easily to platforms < PHP 5.1 (for example RHEL4 - yes, I know RHEL4 probably isn't going to update PEAR, but there are people like me running EL derivatives with backported versions of key packages like PHP/PEAR etc.) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review