why bloated packages are bad (a case for splitting up large packages)

Hello, There has been a lot of wrangling over PEAR_ErrorStack splitting off from PEAR recently. It is important to understand why this is a good idea. PEAR_ErrorStack is a single file. Developers wishing to use PEAR_ErrorStack at present have implicit dependencies on Archive_Tar and Console_Getopt because PEAR requires them, even though they have nothing to do with PEAR_ErrorStack. Right now, I am debugging bug #5085 which requires downloading .tgzs for File_Archive and its dependencies. Since this is a unit test, I have to download the complete dependency tree. This means that I must download these packages just to test a problem with one dependency on a package that handles archives: Archive_Tar Auth_SASL Cache_Lite Console_Getopt File_Archive Mail Mail_Mime MIME_Type Net_SMTP Net_Socket PEAR System_Command XML_RPC Ironically, File_Archive even has an indirect dependency on Archive_Tar due to requiring PEAR for the PEAR_Error class. There are also indirect deps on Net_Socket and Auth_SASL because of features included that have nothing to do with extracting and creating archives. Obviously, these dependencies are not actually needed for basic operation of the File_Archive class, but the installer is not smart enough to make these distinctions. A required dependency is a required dependency. This is not a good way to run things. Far better would be several subpackages containing the drivers that allow mailing an archive easily, or other functionality. The MIME_Type is used to differentiate between unknown file extensions I believe (a very good thing), but this will not be used by all users of File_Archive. Because of these extraneous dependencies, File_Archive will never be considered as an option to replace Archive_Tar in PEAR, even though it is more actively maintained and is an innovative new approach to archives. This is by no means the fault of Vincent, who is following the established patterns used in PEAR packages to date because of the way dependencies were so hard to manage with PEAR 1.3.x. I consider this to be a serious flaw in the design of PEAR 1.3.x, maybe even THE flaw, and this is yet another reason I have been slaving away on 1.4.x. I will be happy to address any questions this email raises, but I urge all of you to read the manual sections I have written about package.xml 2.0 and migrating to PEAR 1.4.0 before asking in case they are answered there. Greg