Re: cvs: pearweb /include pear-database.php

Helgi Þormar Þorbjörnsson wrote:

dufuz Tue Oct 26 16:33:52 2004 EDT

  Modified files:                  /pearweb/include	pear-database.php   Log:

- For the bug system:

    Ability to get only pecl packages. extra param added to packages::listAll added for that.

- Added comment to whoIsWho to clarify the types in there a little.

I would like to bring up an important point here, but before I do, this is not a direct response to Helgi's commit, I've been pondering these ideas for a while. The commit is only another catalyst. First of all, PECL != PEAR in any way, shape or form. The only thing in common is that you can install both kinds of packages using the pear installer. However, for the next version of the installer, I'm probably going to be splitting out a special command "pecl" that uses the -n switch to disable php.ini during installation. This will be necessary in order to install or upgrade any shared extensions that would otherwise be in use. Now, currently, all pecl information is sandwiched together with pear information in a single database. This makes for some ugly bugs and even necessary but uglier code to get around them. The only reasonable solution is to completely separate pecl from pear as a separate channel. There should be separate bug systems, a separate database and only the installer in common. Even if the code is common or similar, this separation will make it much easier to handle on the server-side. Another *VERY* important reason this will be necessary is that the next version of the installer includes some rather strict validation rules for things like versioning, that will conflict with the way PECL works - PECL versioning appears to have no relation whatsoever to PEAR versioning, there are plenty of packages that are marked stable as version 0.2.0, and there are releases like 0.1.00 floating around too. If PECL has its own channel, it can use a much less strict validation mechanism, and can even prevent pear packages from being packaged as php releases (only extsrc/extbin would be allowed). At this point, there are technical hurdles to get around, namely getting a working PEAR_Server that could replace the existing pecl server, and rewriting the frontend to take advantage of these changes, so I'm not talking about an overnight change, but this will be a very important process for helping PECL mature without being shackled to PEAR. Greg