Re: Naming clash
| From: | Greg Beaver | Date: | Wed, 26 Jan 2005 13:25:54 +0000 |
| Subject: | Re: Naming clash | ||
| References: | 1 2 3 4 5 | Groups: | php.pecl.dev |
| Request: | Send a blank email to pecl-dev+get-1855@lists.php.net to get a copy of this message | ||
Derick Rethans wrote:
On Tue, 25 Jan 2005, Greg Beaver wrote:When is it ready? :) Derick I would need to make some minor mods to peclweb in addition to merging the code from pearweb to have pecl packages on a different channel. In addition, the unique key in the packages table would need to change to include the package_type field. FYI, Demian Turner is running a test version of pearweb for phpkitchen that will be used to make sure the idea of using pearweb as a channel server works before we go with 1.4.0a1, this will make the transition for pecl.php.net much smoother should a channel be decided on. There are several possibilities here. Because of the need for the -n switch when installing extensions from pecl, I was planning to add a new command "pecl" (oddly enough :) to handle this. It would mean adding a little magic into the pear installer (easy to do) so we would see: $ pear install sqlite SQlite is a pecl extension, please use the "pecl" command $ pecl install sqlite install ok channel://pecl.php.net/SQLite-1.whatever Does this sound reasonable to people? Note: there are some other interesting side effects. #1, all new releases would need to use package.xml 2.0. Fortunately, "pear convert" will automatically convert a package.xml 1.0 to package.xml 2.0, and then any changes can be done with simple editing. In addition, to maintain BC with older PEAR versions, packages would need to be packaged with both a package.xml 1.0 and 2.0, which is also very simple: "pear package package.xml package2.xml" GregLukas Smith wrote:Channels solves this problem elegantly.Ilia Alshanetsky wrote:well this is quite a nasty issue in general and has already bitten us on the soap front iirc. even worse its likely to bite us quite often. however I fear there is little we can do about this aside from ugly prefixes for the project that comes second.pecl_http is my suggestion. Even if we somehow manage to isolate pear & pecl, having 2 packages with the same name would end up causing endless confusion.