Re: bundles

Stig S. Bakken wrote:

Hi Greg, If I understand your proposal correctly, you define bundles as a list of sub-packages that have a "contained by" relationship with the "bundle" package. But you could regard a bundles simply as an empty package with regular dependencies. You would lose the "contained by" relationship, but the overall complexity would be much lower. I know we talked about sub-packages last year, but I'm starting to get cold feet wrt. all the extra system complexity (PEAR is complex enough as is). My main concern is that we are getting quite a few dimensions to consider for dependencies: * package name * release platform (with all the cpu vs. OS vs. vendor fun) * release version * release provides (class/interface/function) Handling four-dimensional dependencies is for brave coders, but it's well-defined enough. Adding sub-packages to this muddies things up, because a package is no longer a package, and a release is no longer a release. What _is_ the difference between DB_mysql and DB#mysql? I think sub-packages would make something that is already complex enough to understand and keep track of, more complex. Simple is good. :) So, by dropping the "contained by" relationship and the concept of sub-packages, we end up with the possibility of having a package that contains multiple packages, all in the same package.xml format. You can still do the "bundling" by embedding the actual package files Example filelist from a hypothetical DB-2.1 package (this one contains some binary packages just for example): <filelist>

    <file role="pkg" name="DB_mysql-2.1.0.tgz"/>
    <!-- ... and maybe something like this: -->
    <file role="pkg" name="mysql-2.1.0-linux_2.4_i386_glibc2.3.tgz"
          platform="linux-*-i386-glibc2.3"/>
    <file role="pkg" name="mysql-2.1.0-freebsd_4.10_i386.tgz"
          platform="freebsd-4.10-i386"/>

</filelist> Simple, straightforward to understand, easy to implement :)

Yeah I see that complexity is a danger and I agree we should be taking a KISS approach even if that is slightly less sophisticated on some minor level. Anyways to me subpackages have always simply been packages with a dep on a given package that will also get uninstalled along with the parent package if the parent is uninstalled (or the parent can only be uninstalled if all subpackages have been uninstalled or something along those lines). Thats all. Now as to bundling I do see Greg's point that managing all the permutations of sensible "bundle" with empty packages can become quite daunting and lead to alot of empty packages quite quickly. For example LiveUser would be a package where you can optionally use Crypt_RC4 in combination with several different backends. So it would be cool to be able to say I want to install LiveUser with all security options and MDB backends and get all relevant optional dependencies installed and at the same time only get the MDB backend drivers (and not the XML, MDB2, DB, PEAR_Auth etc. backends). If I got Greg correctly than this is what he was aiming for with bundles and I dont think this is something we can sensibly provide using empty packages which would need to be created for every bundle we might want to provide. regards, Lukas