Re: a case for subpackages

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 etc. etc. What overhead, specifically, is added that you object to? I see a tremendous amount of user overhead added in my above example. Yes, I do want the option to have sub-subpackages (different templates for converters, for example). Applications that need a large level of customization like PhpDocumentor have them. This would also allow users to bundle their own templates up and install them using the pear installer - a much better way to do things than requiring some kind of odd directory copying business like we do now. Implementing subpackages doesn't create any extra overhead in the most commonly executed pear commands. It only requires: --no change to the installer, except perhaps an optional command to install subpackages, but that's sugar, as --alldeps would do this --only a single change to the uninstaller, to either optionally uninstall all subpackages as well, or automatically uninstall them on uninstall --no change to the registry --change to pear list and pear remote-list so that it can hide subpackages in the list of packages, and display them if you pear list package or pear remote-list package I've almost finished the code for the last 2 options, so you can see it. Regards, Greg