Re: bundles

Daniel Convissor wrote:

On Sat, Sep 11, 2004 at 06:09:50PM -0400, Greg Beaver wrote:

[channelname::]packagename[-version|-state][.tar|.tgz][#bundlename] pear::PEAR-1.4.0dev12.tgz#developer

From your description of bundles, they would be groups of packages, such as the PEAR Foundation Classes. So, why is the bundle syntax being tied into a particular package?

as I see it there are 2 kinds of bundles 1) bundles directly related to a specific package's function (including subpackages and external optional deps) 2) a collection of packages unrelated to the function of a specific package I am only referring to #1, as this can be used for subpackages, or for specifying collections of optional dependencies to install. For instance, many packages have a series of optional dependencies relating to different uses. None of these optional dependencies are subpackages, as they are totally separate packages maintained by totally different people. In fact, with bundles, this distinction between an optional dependency and a subpackage becomes unnecessary.

$ pear install PEAR#developer DB#mysql

I wouldn't refer to installing only the mysql stuff from the DB package as a bundle. It seems the concepts of bundles and sub-packages are being mixed together.

see above. In my opinion (and from a technical standpoint), the bundle for category #2 is a different animal, although it could be used, for instance, to distribute a complete application(or package) with all of its dependencies in a single tarball

"#" is an excellent marker for sub-packages. Bundles should be referred to as packages and maybe have a special precursor indicating it's a bundle.

I have great reservations about mixing installation of packages and bundles of the 2nd variety. I would prefer a totally separate command. pear install-bundle PFC pear download-bundle allPEAR for instance. This would allow the two kinds of bundles to be separate from an end-user's point of view, as they are in reality. However, from a developer's point of view, they really aren't all that different. How is a collection of unrelated packages handled differently from a collection of related packages? They're both specified as the contents of a recommended installation (or of a set of different, named recommended installations). The implementation of package-specific bundles will allow easy installation and uninstallation of groups of packages without guesswork. In other words, if you choose to install a bundle, that bundle must specify *every* package that is needed for the install. $ pear install --alldeps DB#mysql WARNING: --alldeps and --onlyreqdeps are ignored when installing a bundle download of DB OK download of DB_mysql OK install OK [abbreviated, of course] ... two months later $ pear install DB#mssql download of DB_mssql OK install OK ... two years later, this is possible too $ pear uninstall DB#alldrivers uninstall of DB OK uninstall of DB_mysql OK uninstall of DB_mssql OK Because each bundle simply lists packages, it provides a developer-sanctioned shortcut for installation and uninstallation to help the user know what can be safely uninstalled as well as what is absolutely necessary to perform a desired function. No registry information of "this bundle is installed" will be necessary, although commands can easily be created that verify whether all of the components are installed for a bundle or not. In addition, a dependency can specify a bundle <package name="DB" bundle="mysql" recommended="1.7.0"/> allowing clean shifting of external dependencies without having to guess with --onlyreqdeps or --alldeps. The addition of a recommended version for dependencies is crucial to all of this - when a dependency is upgraded right now, it might break the dependent package, there is no way of knowing whether the dependency author actually tested it with the dependent package. package.xml 2.0 will introduce a way to specify "it's OK to use this mysql driver with DB 1.7.0, even though it's newer than the recommended version of the mysql driver for DB 1.7.0, but it doesn't work with 1.6.3" <compatibility> <package name="DB" min="1.5.0" max="1.7.0"> <exclude version="1.6.3"/> </package> </compatibility> and if this isn't present, the upgrade will fail without a --force, and give a warning that although this will probably work, it has not got the compatibility seal of approval. Sure it's more work for developers to do this, but it makes depending on PEAR packages actually possible in a way that is still risky today. I'm always open for "but you haven't thought of X" discussions, of course :), but these are my current thoughts about how bundles of the first variety could be best implemented. Greg