important conceptual update for the installer

Hi, It is impossible to remove any component of any package and release it as a subpackage in the current implementation. Why? Take PEAR_ErrorStack, for instance. I've found several uses for it in the PEAR installer. If I remove it from PEAR 1.3.2, then the pear command won't work. However, if instead I add a required dependency on PEAR_ErrorStack package in PEAR 1.3.2, PEAR_ErrorStack will be unable to install without a --force because PEAR/ErrorStack.php will conflict with the installed PEAR/ErrorStack.php (different packages). Catch-22. The only solution is to add more information to package.xml, such that a subpackage is identified in the dependency clause. <package> <name>PEAR_ErrorStack</name> <min>0.2.0</min> <recommended>0.2.0</recommended> <issubpackage/> </package> The <issubpackage/> tag would tell the installer "This package may conflict with earlier versions of PEAR, but should be installed anyways" another possibly simpler alternative is to simply add a <subpackage> dependency type. <subpackage> <name>PEAR_ErrorStack</name> <min>0.2.0</min> <recommended>0.2.0</recommended> </subpackage> What this really means is that PEAR 1.3.2 can't withdraw PEAR_ErrorStack because its package.xml must be in version 1.0 format - only PEAR 1.4.0 supports the new version 2.0 format. So, the earliest PEAR version that can separate PEAR_ErrorStack from PEAR is version 1.4.1 (or 1.5.0, perhaps), as there must be at least 1 stable release of PEAR that uses a package.xml 1.0 format, but can read package.xml 2.0 format. Important points: 1) it is *crucial* that the <subpackage> dependency be considered informational - it would define a package as being just like any other package except it bears a particular relationship to the parent package of backwards and forwards dependence (the subpackage depends on the parent package, the parent depends on the child package either optionally or absolutely) 2) <subpackage> would only be allowed in <required> and <optional> and not in <group>. This doesn't stop users from using a <package> tag for the same package inside <group> I HAVE NOT IMPLEMENTED THIS YET. I only realized the problem last night, so I'm writing to get informed opinions on the subject. Greg