In a new post to his blog today, Ken Guest talks about the split that's been made in a PEAR package for calculating the dates of holidays (Date_Holidays) for localization reasons.

We decided that this one package should be split into subpackages: one subpackage per region/country. Some advantages of this approach are that each driver / filter / subpackage gets it's own stability and version number - we wouldn't have to keep increasing the version number of Date_Holidays each time a new driver is added or when an existing driver gets a significant number of fixes.

To replace your current version of the package (with all of the regions built in) with a new version that still contains all versions, uninstall the Date_Holidays and grab the "Date_Holidays#all" package. Otherwise, you can check out the PEAR page for the main package and see the subpackage list if you only need one for your area.

Following right on the heels of a different PEAR problem, Greg Beaver has posted about a similar PEAR-related issue that could cause some serious problems for you and your installation.

After investigating (which in my case meant briefly recalling from memory how PEAR actually validates dependencies), I remembered that PEAR validates dependencies twice, once prior to download, and once prior to installation. By the time the dependencies are sorted, PEAR assumes that the sort algorithm properly sorts things.

This is actually a pretty reasonable assumption considering the unit tests that are in place to test this. However, like all regression testing, the unit tests test boundaries and likely cases, but not all possible inputs.

So, to try to figure out where things might have gone wrong, Greg does a little research to find the problem. He discovers that it has to do with the order that the "subpackages" for the dependencies are installed, where the contents of those files are not removed correctly before installation, resulting in a file conflict.

Following right on the heels of a different PEAR problem, Greg Beaver has posted about a similar PEAR-related issue that could cause some serious problems for you and your installation.

After investigating (which in my case meant briefly recalling from memory how PEAR actually validates dependencies), I remembered that PEAR validates dependencies twice, once prior to download, and once prior to installation. By the time the dependencies are sorted, PEAR assumes that the sort algorithm properly sorts things.

This is actually a pretty reasonable assumption considering the unit tests that are in place to test this. However, like all regression testing, the unit tests test boundaries and likely cases, but not all possible inputs.

So, to try to figure out where things might have gone wrong, Greg does a little research to find the problem. He discovers that it has to do with the order that the "subpackages" for the dependencies are installed, where the contents of those files are not removed correctly before installation, resulting in a file conflict.