Description: ------------ This is a PEAR2 thing. I believe that everything in this bug can already be achieved with PEAR 1.4 and a custom validation package; this feature request is purely about: a) shipping an additional, minimal validator b) making it the default Considering the PEAR Installer separately from PEAR the set of packages, the *default* validation done on a package.xml file should be as minimal as possible, with more strict requirements being enforced for packages in the PEAR channel, rather than the other way round as at present. The purpose of this is: - to distinguish between "content" and "policy". The former is objective, the latter subjective. "content" means describing intrinsic things about the content, like the version number. "policy" means things like "you really ought to have a description" - to save duplication of metadata between packages and other systems - to keep package.xml files as simple as possible - to ease the learning curve for developers who are new to the PEAR Installer - to make writing documentation for beginners easier, allowing the explanation of "essential" concepts separate from "nice to haves". By "minimal" I mean the minimal set of metadata which: - accurately and unambiguously describes a package - enables the deployment process to take place This should take into account that the PEAR Installer may be used in small teams in private environments, where non-essential metadata may already be maintained outside of the package deployment system, and inclusion in it is therefore unnecessary duplication. ("content" vs "policy" again) I will attach a sample package.xml which I would suggest is "minimal" for the purposes of this bug. However, just to discuss some of the currently-required tags that I would propose removing in more detail: - <lead> - this is a descriptive tag which is nothing to do with the deployment process and is metadata which is likely maintained elsewhere (particularly if you are running a database-driven channel server) - <date> - this is purely descriptive and often held elsewhere - <version><api> - the API has less meaning in the context of an application than it does for a library, and it may already be implied by the package version where a policy on API changes exists. - <description> - whilst this should "probably" be present in most cases, again in a small team environment it may be superfluous as the <summary> is probably enough to enable ready identification of a package, with full description/docs held elsewhere - <notes> - again, this is purely descriptive - <phprelease> - this should default to 1. I must re-emphasise that I am ***NOT*** saying that the above tags are not useful, just that they are not necessary in all environments and therefore shouldn't be *required* by default. One possible one which I'm not sure about is: - <stability> - often, this is implied from the package/API versions where a policy on those is in place.

OK, I've looked into it and this can't be done with a custom channel validator as far as I can see (I'm just looking at PEAR1 here; I haven't looked into PEAR2 yet). The checking of base required tags is done in PEAR/PackageFile/v2/Validator.php, called from PEAR/PackageFile/v2.php. I can't see an easy way to overload this, so solving this is non-trivial.

Here is my suggested minimal package.xml, moved over from bug #10672: <?xml version="1.0" encoding="UTF-8"?> <package version="2.0" xmlns="http://pear.php.net/dtd/package-2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://pear.php.net/dtd/package-2.0 http://pear.php.net/dtd/package-2.0.xsd"> <name>Foo_Bar</name> <channel>pear.example.com</channel> <summary>A package to handle foo</summary> <version> <release>1.0.0</release> </version> <stability> <release>stable</release> </stability> <license>Whatever</license> <contents> <!-- normal contents go here --> </contents> </package>

We will probably never implement this.