Re: a case for subpackages

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 :) Tomas V.V.Cox On Monday, August 25, 2003 6:56, Greg Beaver wrote: > Hi, > I'd like to make a case for subpackages in PEAR. First of all, the > definition of a subpackage is dependency-based, and would not require > any modification at all to package.dtd, or installation code (even the > patch I provided for automatic dependency resolution would be unaffected). > A subpackage is a package that depends on another package that > optionally depends on the subpackage. > In package.xml terms that means: > Package Main's package.xml dependencies: > <deps> > <dep type="pkg" ... optional="yes">Main_Subpackage</dep> > </deps> > Package Main_Subpackage's package.xml dependencies: > <deps> > <dep type="pkg" ... optional="no">Main</dep> > </deps> > This relationship will never occur in a standard dependency. > In practical terms, this means that subpackages must be uninstalled with > the main package, but need not be installed with the main package. > Obviously, anything that must be installed with the main package is > either a standard dependency or a part of the main package itself. > Subpackages by definition cannot exist as standalone packages - they > depend on the main package to exist at all. > A side effect of this definition is obvious: if one wants to uninstall > the main package, it would be pointless to keep any subpackages > installed, as they can't be used without the main package. There are > countless examples. MDB drivers, phpDocumentor Converters, Log > children, Cache containers - all of these are subpackages, and it should > be possible to install some, all, or none of them (for the odd cases > where a user only uses a custom driver/converter/container). > Why separate subpackages from the main package? > 1) Subpackages often have a very different stability level from the main > package, and users who only want stable code should not be forced to > read documentation just to determine the stability of a package. > 2) Upgrading a subpackage that has changes is much more efficient in > both time and bandwidth than upgrading the entire package at once. New > subpackages can be released without a new release of the main package > 3) Applications can depend on a minimal set of subpackages, reducing > dependency bloat > This patch implements subpackage handling for uninstall. If --nodeps is > passed, subpackage uninstall will not occur. Note that the patch was > made against CVS - if you wish to test both this and the > auto-dependency-resolution patch, this one must be applied first, as all > modifications to Installer.php in this patch occur after the install() > method > Greg -- Tomas V.V.Cox mailto:cox@idecnet.com