PEAR2 standards: anything good at all?

Hi, After re-reading the "PEAR2 standards", "PEAR2 require" wiki pages and (most of) discussion on pear-dev, I'm beginning to think that these so-called standards should be ditched in their entirety. The problems that PEAR2 is supposedly trying to solve can be easily put into three categories: 1) Nonexisting 2) Caused by tools outside PEAR 3) Those having solutions much worse than the problem itself It is claimed that unzip-and-go is a good thing. But let's think aloud: who is the target audience for unzip-and-go? I suppose these are the people * unable to use PEAR installer (those who don't *want* to set up a PEAR installer on the server may use its remote installation capabilities) * unable to set up their include_path (which is a pretty standard task among programming languages) So we provide a way for these people to not use a PEAR installer and not set up an include_path, but "Of course, the people need to take care about dependencies themselves if they do not use Pyrus." O-o-o-kay, now let's think aloud again, what are the chances that a person unable to set up an include_path will be able to properly take care about dependencies? I'd say close to zero. So we'll have way more stupid questions on pear-general and more bogus bugs in the tracker. Also please note that several PEAR packages were once provided as unzip-and-go with PHP (instead of bootstrapper for PEAR), some of the developers should still remember what a support nightmare that was. Now another "problem" is that PEAR installation is not relocatable. Since we already covered unzip-and go, let's presume that we are talking a real installation here. The proposed solution is to have a data_dir.txt file in the installation root that'll contain the name of data directory. Nice. But if I relocate the installation, will the file automagically contain the name of the dir I relocated to? No? So, is there a huge difference between editing this file by hand and doing a mass search-and replace that's required now? require_once controversy was already covered a lot here, my opinion is: * slow require_once in APC is a problem of APC, not PEAR. APC developers are aware of it and are solving it, so sometime our optimizations may become counter-productive. * require_once is faster without APC. If we're targeting PHP6 which will (supposedly) have APC built in, why aren't we using namespaces, too, going instead for PEAR2_Obnoxiously_Long_Class_Names? * Anyone else smelling a reincarnation of PEAR_Error here? Also people were talking a lot about "speed improvements". Let's not forget about memory: if we fill up the server's memory with dozens of useless classes and begin to swap, we'll have more serious problems than a couple of microseconds wasted on require_once (this is mentioned on "PEAR2 require", though).