php-pear 1.6.1

[Remi Collet]

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

[Joe Orton]

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

[Tim Jackson]

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

[Remi Collet]

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.

[Joe Orton]

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

php-pear 1.6.1 On the road...

[Remi Collet]

>  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..

php-pear 1.6.1 On the road...

[Remi Collet]

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.