Re: bundles

On Mon, 2004-09-20 at 01:20, Greg Beaver wrote: > Stig S. Bakken wrote: > > > But what are we trying to fix here? I have to admit I don't really see > > a problem that needs fixing :) Do people *need* to be able to choose > > which parts of a package/bundle they want to install, and won't optional > > dependencies solve this? We're talking about a good amount of > > complexity for (IMHO) questionable gain. > > Optional dependencies serve a useful purpose right now, but they aren't > quite specific enough. An optional dependency is something that is > literally optional - it is never, ever absolutely needed in order to > perform a function, but makes that functionality better. > > Many packages have been forced to abuse this definition, and instead use > it to define a dependency that is *required* for fringe use. > > Also, there are other situations where a dependency is not optional, but > should be in a separate package with separate release cycles. > > I know you haven't had as much time to read all of the threads, so I'll > re-summarize the problems I've run into again and again. > > 1) Larger packages contain too many elements > > PEAR consists of (or will consist of): > > - the installer > - PEAR_ErrorStack > - PEAR_Exception > - Console_Getopt > - System > > There are significant bugfixes in PEAR_ErrorStack that need to be > released, but I can't just release the entire PEAR package because 1/5 > of it has changed. Console_Getopt can never be changed because it will > instantly break all PEAR installations (and it did a few months ago). > System is a component that could easily be a separate package. IMHO, this is about build/release management, and should be dealt with before packaging. In my experience, the best solution to this, bundles or not, is to have a stable (CVS) branch for each PEAR major.minor release, ala http://pear.php.net/manual/en/standards.cvs.php (that page is actually a bit misleading, since it calls branches QA_n_n_n, while QA_n_n is really what you want according to current CS). The PEAR package is a bit special actually, and if I did this today I would embed Console_Getopt and System differently, and not have any package dependencies in the PEAR package. > 2) Different chunks of a large package have different stabilities. > > Right now, PEAR is stable, but PEAR_ErrorStack is alpha. This is > inherently confusing to users. Yes, it is. But having an alpha package bundled with a stable bundle/package is no less confusing! The package manager isn't the right place to deal with this sort of problem. > 3) People often want only a sub-section of a package, such as File_VFS, > which is stuck forever as a subpackage of File, and can never be > extracted because of BC issues. With the bundling solution I've > described, it will be possible to extract File_VFS, finally, into its > own package, while maintaining BC with the existing File package. But is this is general problem, or a specific one caused by some bad decisions done for the File/File_VFS packages, or some other "historic reason"? Would PEAR developers repeat the same mistake again now that we've learnt these things the hard way? I'd prefer that we all learn from these issues, fix the specific problems for those specific packages, and just make sure it doesn't happen again. > 4) Once a package is split up, it's very difficult to coordinate the > pieces, especially at uninstall time. But you have that problem regardless, as long as it is possible to upgrade part of a bundle separately. It simply has to be dealt with either way. > You probably missed the message (or maybe you didn't and hated it :) > where I described the solution I think will work best, it's at: > > http://news.php.net/php.pear.dev/33393 I may or may not have ready it :) news.php.net times out here though, but if you give me the subject+date I can find it in my own archive. - Stig