Re: a case for subpackages

On Wednesday, August 27, 2003 20:30, Greg Beaver wrote: > Tomas V.V.Cox wrote: >> Excuse me but I don't see the need quiet clear. >> >> $ pear install Submain >> Submain needs Main >> $ pear install Main >> ok >> $ pear install Submain >> ok >> $ pear uninstall Main >> can not uninstall, Submain depends on Main >> >> >> Where's the problem? I guess that "subpackages" adds extra overhead we >> don't really need, without saying that we have to warn the user that >> we are going to uninstall his packages :) > Here's the problem: > $ pear install --alldeps PhpDocumentor > [lots of information skipped] > Install OK: PhpDocumentor > 5 months later: > $ pear uninstall PhpDocumentor > can not uninstall, PhpDocumentor_HTML_frames depends on PhpDocumentor > $ pear uninstall PhpDocumentor_HTML_frames > can not uninstall, PhpDocumentor_HTML_frames_default depends on > PhpDocumentor 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 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. -- Tomas V.V.Cox mailto:cox@idecnet.com