Re: bundles

Daniel Convissor wrote:

Hey Greg: On Sun, Sep 12, 2004 at 02:31:20PM -0400, Greg Beaver wrote:

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.

Uh, okay. :) I think #2 when using the term "bundle." Looks like we need to come up with two distinct terms for these different "bundles" and have those terms documented/defined somewhere.

Yeah I am with Dan here.

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

Rather than taring them all together, I was more thinking that the channel server would have a "bundle" database saying which files get shipped for a given "bundle."

Both should be supported. Remember people might want to download or create these bundles themelves without having to run their own channel server.

$ 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]

I trust that's only a quick example that hasn't been thought through all the way. The notion of only being able to install only certain scripts from a package is going to lead to a gigantic mess. I don't think that's your intention, but I'm asking just to make sure.

I presume Greg expects developers to chop their pckages into sensible subpackages and not giving the users the ability to select specific files. Let me brainstorm some related topics. Currently we have alot of packages that support different backends, optional security improvements etc. Especially for the different (database) backends alot of packages already support 3 difference abstraction layers and usually users only want one. So for that users will eventually be able to select what they want at install time. Now the question is if we want to enable users to set those selections globally similar to how gentoo allows you to. So setting the global option "DB" would set the "only install the DB backend if relevant" for every package being installed. Thinking about it I now understand why Greg is using the # for both bundles and subpackaging (for lack of a better term). Essentially the # syntax is about being able to pass options for a specific package within all of the package that were listed in the pear command (Greg actually stated this, so I am just trying to find my own words for what he was saying .. I hope). regards, Lukas