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

Hi ! I think a good way to avoid these depencies would be a system like the gentoo portage system. When you install a package, you can set serveral USE flags..it's like the configure-options. For example: www-client/mozilla-firefox-1.0.6-r2 -debug +gnome -ipv6 +java -mozcalendar +mozdevelop -moznoxft +mozsvg +truetype +xinerama -xprint The USE flags with a + are compiled into the "program" and the thing with a minus not. Like this we could write a feature for PEAR where you can specify several options for each package. I think thats a good idea but hard work :/ greets - Benny On Sun, 2005-08-14 at 22:43 -0500, Greg Beaver wrote: > 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 >