Re: better management of php-src/pear and PEAR's future in php

From: Date: Fri, 17 Jul 2009 00:36:18 +0000
Subject: Re: better management of php-src/pear and PEAR's future in php
References: 1 2 3  Groups: php.internals php.pear.dev 
Request: Send a blank email to internals+get-45010@lists.php.net to get a copy of this message
On Fri, Jul 17, 2009 at 2:23 AM, Greg Beaver<greg@chiaraquartet.net> wrote: >> Is it possible to have one single phar for all platforms? That would >> already make the whole thing easier to manage. >> > This would be more challenging to do, but may be possible.  The biggest > problem is that go-pear is interactive, and install-pear is not. > > One thing that is good to note is that both go-pear/install-pear may be > obsoleted by Pyrus since it doesn't need to be installed to work.  The > only thing that we'd need to distribute would be scripts to invoke > Pyrus.  My question is mainly whether to make stub "pear" and "pecl" > scripts that will invoke Pyrus, and if these should pretend to be PEAR > (support some of the more obscure things PEAR supports). Even better :) >> New tools, new commands. How different is it to install a package? > Basic stuff is all the same, install/upgrade/uninstall work as PEAR > does, identical syntax and all.  Some of the more obscure stuff has been > removed, such as --soft, --register-only and --ignore-errors. > Configuration has changed a bit, and the config-set command has been > replaced with just "set"  The "info" command performs the duty of both > info and remote-info, and remote-list has replaced list-all.  In > addition, the --installroot option as implemented by PEAR (which was > always strange) is gone, --packagingroot is the option for those doing > RPM building. > > Pyrus, however, is alpha, which is why I'm asking what is really > important, we can still change it if anything is really crucial. I would go with the new syntax, there is no need to keep BC here. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org

« previous php.internals (#45010) next »