I just offered an option that may work, bypassing the need for the Pear/Pecl binary, one that builds a managed RPM of any Pear/Pecl module.
Understand I recently built several packages, including the Oracle Call Interface (OCI8) module for both PHP 5.1.6 (php) and PHP 5.3.3 (php53). No Pear/Pecl was required, even though the package is normally built by Pear/ Pecl, just the RPM SPEC meta that provides many of the same facilities. It would be nice if there were more automated tools around this that crank out SPEC/RPM files (kinda like cpanspec for Perl, R2spec for R, etc...), but the commonly used metas in SPEC files seem to do the job (I'm still learning all the details myself). But the nice thing about using the common metas is that I'm not installing things outside of RPM. As far as RHEL5 v. RHEL6, if you're upgrading to the add-on software to the absolute latest, upstream release, then consider migrating to a more recent release of your platform (RHEL6, even Fedora if required). Otherwise, stick with older versions. E.g., you mentioned Horde. Horde 3 [1] is in EPEL5 and maintained -- even EPEL6 and F15 itself as well. After all, beyond PHP, there might be something else that need to also be rebased for Horde 4 in RHEL5. I find that leveraging the knowledge of Fedora maintainers, as they some of the most insightful and helpful people in pointing out these details and dependencies, because they maintain the packages across both Fedora and EPEL (for RHEL). They'll quickly let you know if you're entering the realm of forcing leading edge applications on mature, trailing edge platforms, and the issues that will result. [1] Horde at Koji: http://koji.fedoraproject.org/koji/packageinfo?packageID=2047 As far as Red Hat products and releases, I cannot answer for Red Hat. But any time I see a concurrent release option, like php53, I don't expect everything to be included and work as it did for the base release. Same deal with GCC and other, concurrent options of other languages and run-times, compiled, interpreted, etc... E.g., there is also the python26 stack in EPEL5 as well. It's nice to see Red Hat release a concurrent PHP version in RHEL5 so it matches RHEL6 (and the community do the same for Python in EPEL), but it's still a concurrent release and I don't expect it to have everything as the base. Opening a Bugzilla is a great move, of course. Leveraging other Red Hat representatives is also ideal. Lastly, although I cannot answer for Debian, as a former Debian maintainer, understand Debian does not have the commercial ISV requirements to maintain strict ABI/API compatibility in a release like Red Hat does in the Enterprise Linux platform. Changing in and out different versions, fully rebasing core components and languages, is an option in Debian. Base PHP is 5.1.6 in RHEL5, including 5.6 itself. Again, I was just offering an option. Consider building a RPM using the Pear/Pecl meta tags/templates in SPEC files. I've done a couple now. -- Bryan P.S. Guess what? I just installed "php-pear" on a "php53" stack (no conflicts) and tried "pecl install oci8" and it worked! Although with many deprecations in the tool output, it would be ideal for the utility to be updated for PHP 5.3, it still works. ----- Original Message ---- From: D G Teed <[email protected]> To: Red Hat Enterprise Linux 5 (Tikanga) discussion mailing-list <[email protected]> Sent: Tue, June 21, 2011 7:22:23 PM Subject: Re: [rhelv5-list] php53-pear request - bug 673521 On Tue, Jun 21, 2011 at 4:09 PM, Bryan J Smith <[email protected]> wrote: > I've actually built some Pear/Pecl components with the RHEL5.6 php53 (5.3.3) > stack installed more recently, using the SPEC meta tags to package nicely into > RPMs. I prefer it over running the scripts to build components outside of > RPM. But your experiences may vary. Can Pear itself be upgraded this way? This is what is holding up use of Horde via pear installation method. If so, please give an example or a URL noting how pear can be updated within the Redhat environment. > -- Bryan > > P.S. For the latest software requirements, have you considered RHEL6? RHEL5 >is > over four (4) years old, based on a Fedora release even older. I would suspect > several, 2011+ era components that have dependencies on PHP 5.3+, Python 2.6, > etc... will cause various issues that Red Hat won't be able to always address. RHEL 6 would require installing on another hardware system. I don't have experience with recent RH upgrade in situ, but my gut reaction says don't do that with a production system or you are looking at hours of downtime before all features function as they did before. So this is going to wait until there is newer hardware for this system, which will be a few years away since it is only one year old. In my point of view, Redhat 5.0 came out over four years ago. Redhat 5.6 is current (what we are running) and 5.7 is around the corner. Redhat 5 just released php53 in January 2011, so it is false to talk of this being way out of date. It makes sense for Redhat to follow up the php53 release with the missing Pear update. Perhaps it will drive home the point further that there is something busted in Redhat if I show what happens in Debian 5, which is also a number of years old and provides php 5.2.6.... On a Debian 5 system: # pear list Installed packages, channel pear.php.net: ========================================= Package Version State Archive_Tar 1.3.2 stable Console_Getopt 1.2.3 stable PEAR 1.7.1 stable Structures_Graph 1.0.2 stable # pear upgrade-all Will upgrade channel://pear.php.net/structures_graph Will upgrade channel://pear.php.net/pear Will upgrade channel://pear.php.net/archive_tar Will upgrade channel://pear.php.net/console_getopt pear/Console_Getopt requires PEAR Installer (version >= 1.8.0), installed version is 1.7.1 downloading Structures_Graph-1.0.4.tgz ... Starting to download Structures_Graph-1.0.4.tgz (30,318 bytes) .........done: 30,318 bytes downloading PEAR-1.9.3.tgz ... Starting to download PEAR-1.9.3.tgz (295,774 bytes) ...done: 295,774 bytes downloading Archive_Tar-1.3.7.tgz ... Starting to download Archive_Tar-1.3.7.tgz (17,610 bytes) ...done: 17,610 bytes downloading XML_Util-1.2.1.tgz ... Starting to download XML_Util-1.2.1.tgz (17,729 bytes) ...done: 17,729 bytes upgrade-all ok: channel://pear.php.net/Structures_Graph-1.0.4 upgrade-all ok: channel://pear.php.net/Archive_Tar-1.3.7 upgrade-all ok: channel://pear.php.net/XML_Util-1.2.1 upgrade-all ok: channel://pear.php.net/PEAR-1.9.3 PEAR: Optional feature webinstaller available (PEAR's web-based installer) PEAR: Optional feature gtkinstaller available (PEAR's PHP-GTK-based installer) PEAR: Optional feature gtk2installer available (PEAR's PHP-GTK2-based installer) PEAR: To install optional features use "pear install pear/PEAR#featurename" # pear list Installed packages, channel pear.php.net: ========================================= Package Version State Archive_Tar 1.3.7 stable Console_Getopt 1.2.3 stable PEAR 1.9.3 stable Structures_Graph 1.0.4 stable XML_Util 1.2.1 stable If Debian 5 can do this, why can't Redhat 5? --Donald > > ----- Original Message ---- > From: D G Teed <[email protected]> > Sent: Tue, June 21, 2011 2:00:51 PM > > There is an existing bug report for this. > https://bugzilla.redhat.com/show_bug.cgi?id=673521 > We don't have support - can't afford the fees. > > I've looked at the 5.7 release notes and nothing about php or pear > on the horizon. This bug report is now a few months old. > > This shortcoming impacts projects built on php. For example, > it is impossible to install the current Horde Webmail software > based on Horde 4 within the pear environment provided by Redhat. > > It is ridiculous we have to go 3rd party repos or compile > from source if we want updates like this very soon. > > I prefer to install packages managed by a package manager. > Redhat can make it a new package as was done with php53 > and then we have a way to reinstall with the older php 5.1 stuff > if there are issues. > > The user list at horde suggest using the repo Les RPM de Remi > but I'd much rather not get into another dependency tree and > watch my OS start showing cracks in the foundation > a year later. > > _______________________________________________ > rhelv5-list mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/rhelv5-list > _______________________________________________ rhelv5-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv5-list _______________________________________________ rhelv5-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv5-list
