Bug 173810 - RFE: php-pear should be built separately from main PHP package
RFE: php-pear should be built separately from main PHP package
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: php (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Joe Orton
David Lawrence
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-21 09:53 EST by Tim Jackson
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-12-01 17:21:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tim Jackson 2005-11-21 09:53:37 EST
Although PEAR is currently bundled with the main PHP distro, having PEAR built
as part of the main PHP build is rather inconvenient.  It prevents upgrading
PEAR separately (upstream PEAR is now considerably newer than the PEAR bundled
with PHP, and includes highly useful fixes to RPM handling). Additionally, as we
have seen recently, security or other bugs within bundled PEAR packages (e.g.
XML_RPC) require the rebuild of the entire PHP suite to fix a couple of lines of
runtime PEAR code.

Ideally php should be compiled using --without-pear, and a separate PEAR SRPM
should be made available. I have done some preliminary investigation and it
seems that the script on http://go-pear.org/ is able to bootstrap a minimal PEAR
installation into a buildroot, which could then be packaged up as php-pear (not
forgetting appropriate Provides: - see bug #173806)

As an aside, Gentoo have apparently reached the same conclusion:
http://www.sebastian-bergmann.de/blog/archives/467-Upcoming-PEAR-Changes-in-Gentoo-Linux.html

NB a repackaging could also potentially slim down a bit - as per bug #173808
Comment 1 Joe Orton 2005-11-23 11:17:45 EST
Tim, thanks for filling all the reports.

I definitely agree that splitting out php-pear to a separate source RPM is a
good idea.  It really needs to be done from a tarball not from running a script;
have you attempted that?

The PEAR-x.y.z.tgz tarballs available from: http://pear.php.net/package/PEAR
should be the starting point.  Possibly the pear/install-pear.php script from
the PHP tarball is needed to boostrap the installation.
Comment 2 Tim Jackson 2005-11-23 12:24:00 EST
Yep, I appreciate it needs to be built from a source tarball to be packaged
properly. I only meant using go-pear to do a local installation in conjunction
with the source tarball, not trying to pull it in remotely (I'm not sure if it
can use a local source rather than remote though). I have been poking around
with the PEAR-1.4.5.tgz tarball a bit. I hadn't yet looked at how the PHP source
tarball installs PEAR, but the pear/install-pear.php script from the main PHP
tarball looks like it's what we should be focusing on.

I'll dig a bit deeper when I get a chance; at the moment I'm trying to roll up
some of the low-hanging (and more urgent, for me) fixes (e.g. bug #173806, bug
#173814, bug #173980) into a local build so that I can install a vanilla
(locally-built) php/php-pear RPM and be able to do "pear makerpm [package] &&
rpmbuild -ba [spec]" and actually get an RPM that works to at least a basic
level of usefulness and conforms to conventions.
Comment 3 Joe Orton 2005-12-01 12:27:44 EST
I've checked in initial php-pear packaging now, it will be built shortly along
with 5.1.1.
Comment 4 Joe Orton 2005-12-01 17:21:13 EST
php-pear-1.4.5-2 on its way to Raw Hide, file bugs if there are problems.

Note You need to log in before you can comment on or make changes to this bug.