Re: a case for subpackages

Tomas V.V.Cox wrote:

The only thing I see here is that 'uninstall' should show all the dependencies you'd break: $ pear uninstall PhpDocumentor can not uninstall: PhpDocumentor_HTML_frames depends on PhpDocumentor PhpDocumentor_HTML_frames_default depends on PhpDocumentor $ pear uninstall PhpDocumentor_HTML_frames PhpDocumentor_HTML_frames_default PhpDocumentor uninstall ok That is one possible solution, yes

The DependecyDB would make sense here, but that can be done without it too. I think that --alldeps is dangerous, imagine a package that marks a dependecy on PEAR, would end uninstalling all, or a package that depends on Console_Getopt would break the pear command. To mark an optional dependency does not mean that a package is a subpackage, so you'll need to introduce another tag in package.xml, ending in the overhead I was talking about. You are right, however I wasn't clear. I didn't mean to imply that an optional dependency was a subpackage, it's a 2 way dependency. The only way that a package could cause the uninstallation of PEAR would be if PEAR also has a required dependency on that package. I.e., if package Foo has an optional dependency on PEAR, and PEAR has a required dependency on Foo.

I agree that pear uninstall --alldeps is dangerous, that was my initial instinct. Your example of depending on Console_Getopt proves the point. maybe pear list --alldeps Packagename would be useful? (or put that information in pear info?) Greg