I know that my command of English is not as good as my command of some other things in life, so I will try my best to be clear.
There are several confusions voiced in
Wez's post that need to be addressed:
- is package.xml 2.0 required
- why are Greg and others pestering pecl devs to use package.xml 2.0
- is it really necessary to support package.xml 1.0 and 2.0
- do I need to use PEAR_PackageFileManager to generate a valid package.xml
1) is package.xml 2.0 required
No. all packages past, present and future that use package.xml will continue to work with the PEAR installer. There are no plans to change this. Let me reiterate: all PEAR and PECL packages will continue to work with package.xml 1.0. Packages that do not need the new conveniences and features of package.xml 2.0 do not need to use it.
2) why is Greg pestering pecl devs to use package.xml 2.0
In order to make pecl.php.net its own channel, there is a bit of hackishness inside the PEAR installer. Dependencies on pecl packages are logically impossible with package.xml 1.0, because there is no place in the dependency format that allows one to link a package and an extension.
Currently, if you type
"pear install PDO"
it fails with PEAR 1.4.0, because the way to install pecl packages is:
"pecl install PDO"
This is a bit of magic because we've had problems with installing extensions that are loaded in php.ini, as the old one can't be deleted. The pecl command actually functions in the same manner as if one had typed:
"pear install pecl/PDO"
except that php.ini is not used by the pecl command so that extensions can be unloaded from memory. This presents a bit of an issue for packages like PDO_mysql that require PDO to be installed, and implement this with a <dep type="ext" rel="ge" version="0.whatever">PDO</dep> tag. If the extension is unloaded, then this means you can never upgrade PDO_mysql unless you use the --force option.
package.xml solves this elegantly. By using this dependency tag:
<package>
<name>PDO</name>
<min>0.whatever</min>
<providesextension>PDO</providesextension>
</package>
now, suddenly, it is possible to upgrade PDO_mysql. Why Because this dependency first checks to see if the PDO extension is loaded in memory. If not, then it checks to see if the package is being downloaded (which enables things like "pecl install PDO PDO_mysql"), and then finally to see if the package has been installed. In other words, the new features of package.xml version 2.0 will make it possible for end-users to actually install PECL extension packages with the same one-liner-command-without-thinking that is now possible with PEAR packages.
3) is it really necessary to support package.xml 1.0 and 2.0
if users have been able to install your package using PHP versions older than 5.0.0, then I would highly recommend that a package.xml be included in the package to allow them to install it, as users of PHP 4 are not likely to be as willing to upgrade their PEAR package to the cutting edge. However, if you are using package.xml 2.0 because of new features added in package.xml 2.0 like custom file tasks or multiple release sections, then it is probably not worth it, your PEAR 1.3.x users will not benefit from a hobbled package.
Let's not forget: PEAR 1.4.0 works on all of the PHP versions that PEAR 1.3.x worked on, and fixes a number of critical bugs in PEAR 1.3.x. For instance, file conflicts between packages are not checked for in PEAR 1.3.x properly, and dependencies of installed packages are not checked fully when installing/uninstalling other packages.
4) do I need to use PEAR_PackageFileManager to generate a valid package.xml
No. PEAR_PackageFileManager does eliminate variables if you are maintaining both package.xml and package2.xml, as it can generate a guaranteed valid package.xml/package2.xml from a single script. It is not required. I maintain package-PEAR.xml and package2.xml by hand with no trouble in the PEAR package itself.
In short, when I said that Wez's post was FUD, these reasons above are why. I hope this clears up confusion, without bruising egos - I just want people, particularly PECL devs, to understand how I have their best interests in mind with both the new features and the way they are implemented in PEAR 1.4.0 and package.xml 2.0
