Joe Orton a écrit :
On Tue, Jul 10, 2007 at 08:57:43PM +0200, Remi Collet wrote:
I could probably push php-pear 1.6.1 to devel. Of course, if you agree to use a "home made" install-pear-nozlib.phar because upstream still provides 1.5.4.
I don't like that idea still. Can you bring this up on the list so we can all discuss it? I think there was a way to bootstrap from the .tgz releases instead, which we could switch to.
The solution seems to use (very short resume) : php install-pear.php *.tgz
Work a little on this, here is my specfile :
http://remi.collet.free.fr/rpms/SPEC/php-pear-test.spec http://remi.collet.free.fr/rpms/SRPMS/php-pear-1.6.1-3.fc7.remi.src.rpm
Of course, build work in mock : http://remi.collet.free.fr/rpms/extras/php-pear-1.6.1-build.log
It only use upstream .tgz and "install-pear.php" from CVS (the one which is bundled in the .phar)
Some cleanup from old 1.5.x are no more required (use of INSTALL_ROOT), some still needed (pear.conf)
Remi
On Sun, Jul 15, 2007 at 11:47:16AM +0200, Remi Collet wrote:
The solution seems to use (very short resume) : php install-pear.php *.tgz
Thanks for working on this!
That does seem a lot cleaner than the stuff from PLD which was the other proposal to bootstrap from a .tgz. But it's still essentially a hack because it relies on using install-pear.php extracted from PEAR CVS :(
Tim J - did you get anywhere with improving the management of the release .phars upstream?
If we are resigned to the fact that there will be no traction on that issue upstream then I think we should go with Remi's method described here. Any dissent?
joe
Joe Orton wrote:
On Sun, Jul 15, 2007 at 11:47:16AM +0200, Remi Collet wrote:
The solution seems to use (very short resume) : php install-pear.php *.tgz
Nice.
That does seem a lot cleaner than the stuff from PLD which was the other proposal to bootstrap from a .tgz. But it's still essentially a hack because it relies on using install-pear.php extracted from PEAR CVS :(
True but it's only one file.
Tim J - did you get anywhere with improving the management of the release .phars upstream?
I got agreement but have not had time to follow through to get exact instructions/permission. I still can do that but would rather avoid it if Remi has a reasonably nice solution as it puts another (permanent) dependency on me.
If we are resigned to the fact that there will be no traction on that issue upstream then I think we should go with Remi's method described here. Any dissent?
I haven't actually tried it but it looks smart to me, and solves the permanent phar problem at a stroke.
Tim
Tim Jackson a écrit :
That does seem a lot cleaner than the stuff from PLD which was the other proposal to bootstrap from a .tgz. But it's still essentially a hack because it relies on using install-pear.php extracted from PEAR CVS :(
True but it's only one file.
Do you think it could be possible to ask upstream to add this file to PEAR tarball ? (at top level, as package.xml, not to be installed but only to be used by distro packager)
Remi.
On Tue, Jul 17, 2007 at 12:33:35AM +0100, Tim Jackson wrote:
Joe Orton wrote:
Tim J - did you get anywhere with improving the management of the release .phars upstream?
I got agreement but have not had time to follow through to get exact instructions/permission. I still can do that but would rather avoid it if Remi has a reasonably nice solution as it puts another (permanent) dependency on me.
OK, fair enough, let's go with Remi's solution. Remi, please feel free to go ahead and commit your changes to upgrade to 1.6.x!
Regards,
joe
OK, fair enough, let's go with Remi's solution. Remi, please feel free to go ahead and commit your changes to upgrade to 1.6.x!
Some works before I commit the new spec :
I build : php-pear-1.5.4-4.noarch.rpm is build from actual spec file in CVS php-pear-1.5.4-5.fc8.noarch.rpm is build using new spec file
## Check the RPM content => OK $ rpm -qlp php-pear-1.5.4-4.noarch.rpm | sort >oldrpm $ rpm -qlp php-pear-1.5.4-5.fc8.noarch.rpm | sort >newrpm $ diff oldrpm newrpm && echo OK OK
$ mkdir new old $ (cd old; rpm2cpio php-pear-1.5.4-4.noarch.rpm| cpio -id) 4336 blocs $ (cd new; rpm2cpio php-pear-1.5.4-5.fc8.noarch.rpm | cpio -id) 4350 blocs
## check the installed files $ LANG=C diff -r --brief old new Files old/usr/share/pear/.channels/__uri.reg and new/usr/share/pear/.channels/__uri.reg differ Files old/usr/share/pear/.channels/pear.php.net.reg and new/usr/share/pear/.channels/pear.php.net.reg differ Files old/usr/share/pear/.channels/pecl.php.net.reg and new/usr/share/pear/.channels/pecl.php.net.reg differ Files old/usr/share/pear/.registry/archive_tar.reg and new/usr/share/pear/.registry/archive_tar.reg differ Files old/usr/share/pear/.registry/console_getopt.reg and new/usr/share/pear/.registry/console_getopt.reg differ Files old/usr/share/pear/.registry/pear.reg and new/usr/share/pear/.registry/pear.reg differ Files old/usr/share/pear/.registry/structures_graph.reg and new/usr/share/pear/.registry/structures_graph.reg differ Files old/usr/share/pear/.registry/xml_rpc.reg and new/usr/share/pear/.registry/xml_rpc.reg differ
## diff are mainly timestamp, and buggy "dirtree" (not used)
All seems OK, so, i go..
Remi Collet a écrit :
Files old/usr/share/pear/.registry/xml_rpc.reg and new/usr/share/pear/.registry/xml_rpc.reg differ
## diff are mainly timestamp, and buggy "dirtree" (not used)
Ok, it's a little bug. Reported upstream with patch proposal :
http://pear.php.net/bugs/bug.php?id=11657
Remi.
php-devel@lists.fedoraproject.org
-
Joe Orton -
Remi Collet -
Tim Jackson