Re: bundles

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 :) - Stig On Sat, 11 Sep 2004, Greg Beaver wrote: > Hi, > > I'm finding things working along quite nicely with channels, and in the > process of revamping the PEAR_Downloader class so I can read the darn > thing, I've designed a method similar to parseDSN() from DB that parses > a package name. Currently, this is the format we have: > > [channelname::]packagename[-version|-state][.tar|.tgz] > > This works nicely, as in > > pear::DB-1.6.5 > pear::Cache-stable.tgz > DB > PEAR-alpha > > etc. > > When bundles are introduced, they will be collections of packages that > are installed together, similar to the way --alldeps or --onlyreqdeps > works. The difference is that bundles can also contain unrelated > packages (such as a bundle of PFC classes) that share no dependencies > but the author has found people want to install them all together. > Bundles can also specify a subset of optional dependencies, to install, > for instance, a particular set of packages needed to process a peculiar > database-oriented function. > > The particulars aside, how about using a format similar to html anchors > for bundles? > > [channelname::]packagename[-version|-state][.tar|.tgz][#bundlename] > > pear::PEAR-1.4.0dev12.tgz#developer > > This command, for instance, would install the PEAR package with the > developer bundle. The developer bundle would include all of the > packages needed to do proper creation and management of a PEAR package. > > My main question, however, is not about the content of bundles, but > about how to refer to them on the command-line. I would like to use an > --option, but this fails if you install multiple packages at once > > $ pear install PEAR#developer DB#mysql > > this hypothetical would install the developer package for PEAR, and only > the mysql drivers for DB. > > A similar syntax could also be used at uninstall-time > > $ pear uninstall DB#full > > to avoid the hypothetical > > $ pear uninstall DB DB_mysql DB_mssql DB_oracle > > Greg > >