Re: <bundle> packages from channels

Travis Swicegood wrote: > Howdy all... > > Currently the PEAR Installer won't install a <bundle> package from a > channel. I can think of no valid reason for this. Currently it will > download the package, unpack, then say "oh wait, can't do anything with > it, it's a bundle." Installing a bundle from a file does exactly what > you'd expect when it's a file. > > To my ill-informed eyes, this seems like a rather stupid handicapping > for no good reason. I would be happy to be proven wrong, though. Is > there some valid reason for not handling a bundle from a channel? You > loose the ability to create a meta package on a channel that bundles > everything you need. > > In the PEAR world, it would be something like a Text or Testing or > Services package that contained everything from those categories in one > download. For me, it's PHPT and its bundling of PHPT_Core and > PHPT_Ensure. I could create an empty package for PHPT and have all of > the other packages as subpackages of it, but then you have to add the > --alldeps and there's an increase (albeit slight) in bandwidth as you > have to negotiate the download of multiple files. --alldeps is only required for optional dependencies. required dependencies are always automatically downloaded without additional command-line. > 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. 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). Greg