[Bug 226295] Merge Review: php-pear

[bugzilla at redhat.com]

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 at timj.co.uk  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.