a case for subpackages
| From: | Greg Beaver | Date: | Mon, 25 Aug 2003 04:56:46 +0000 |
| Subject: | a case for subpackages | ||
| Groups: | php.pear.dev | ||
| Request: | Send a blank email to pear-dev+get-20474@lists.php.net to get a copy of this message | ||
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