Re: Re: <bundle> packages from channels

/me bumps... Am I the only one that cares about channel based bundles? -T On Mar 26, 2008, at 5:41 PM, Travis Swicegood wrote:

On Mar 26, 2008, at 4:13 PM, Gregory Beaver wrote:

--alldeps is only required for optional dependencies. required dependencies are always automatically downloaded without additional command-line.

From the sounds of it, this may be what I have to do then. Creating a meta package with a require dependency on the various subpackages that I want to install seems like a hackish way to approach this, however. Especially considering that there is a bundle capability, albeit handicapped (from my perspective), which leads into...

Can anyone shed some light on this decision? I will happily retract my "stupid handicapping" comment if there is some valid reason such as a possible security hole, the uncontrolled creation of nuclear fission, or the very real possibility of bundles called Vendor_PandorasBox that destroy life as we know it. ;-)

If you request "PHPT" and the downloaded package could actually contain any package, there's no way to ensure any kind of clear upgrade path. In other words, when you upgrade to the next version, PEAR has no way of knowing that the previous "version" was package X Y and Z. In other words, the instant you do a bundle, you lose all dependency validation on upgrade, which defeats the purpose of using the PEAR installer at all. Adding "memory" of the contents to bundle would increase the complexity of the PEAR installer an order of magnitude because of questions like "what happens if on upgrade of the bundle, package Z is not present? Should it be uninstalled?" and "what if one of the packages in the bundle is not stable enough, should preferred_state be honored and installation refused?" None of these questions are relevant if the package simply contains stuff to install in a 1-time combination.

This seems like a less-than-useful purpose for the bundles and helps explain why I haven't seen one of them in the wild :-/ From where I'm looking at this from, a bundle should be little more than a wrapper around N packages. Once the installer realizes it has a bundle, wouldn't it make sense for it to just unpack it, then start working through each of the bundled packages to make sure it can install without any conflict and based on the current configuration? An upgrade would then do the same thing: unpack, verify, execute. Based entirely on inflecting what it does based on your description, it sounds like bundles completely circumvents PEAR's built-in checks for things like stability. If that is the case, couldn't I create a bundle that's marked as stable and include alpha or devel stability code and install it without the installer complaining at all? If that is the case, the documentation around bundles, what little there is, needs to be updated to explain this as it would not be the intended behavior of just about anyone who assumes how the bundles will work based on the normal package usage. That said, if it is circumventing the verification, why? Isn't it literally a foreach over a list of packages contained within the bundle? Here's some psuedo-code to get the ball rolling: function handleInstall($pkg, $commitAfterInstallation = true) { if ($pkg->isBundle()) { $bundledPackages = $pkg->getBundledPackages(); foreach ($bundledPackages as $bundledPackage) { $this->handleInstall($bundledPackage, false); } // if we make it through this far, we can commit $this->handleCommit($pkg); } // continue on regular installation if ($commitAfterInstallation) { $this->handleCommit($pkg); } } Just tell me where to look to put this and I'll gladly write a patch. :-D

I'm sorry, but bundles are not a clever way to do automatic dependency downloading. They are a way to distribute many packages for *offline* install in a single tarball, or a handy way to distribute a group of packages that are not immediately dependent on one another (such as your category example).

If this is their purpose, then some documentation needs to be put to this effect. That said, my PHPT example fits the same mold as the category example. PHPT_Core is completely independent of PHPT_Ensure, and any other PHPT_* packages that get produced. The other packages all (currently) have a dependency on PHPT_Core though. What I'm wanting to do is create that loose grouping of packages that fall under the PHPT umbrella, treating it as a "category" of downloads to grab to have the entire bundle of packages. -T --PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php