RE: [PEAR-DEV] Horde components, deprecating old pear compontent

Is there a point in supporting dead packages with the PEAR installer to begin with? Isn't the point of a "dead" package to stay dead and not bother users with its presence? Why not simply publish the sources and TGZs somewhere (e.g. the proposed "graveyard.pear.php.net", or perhaps, to be aligned with PHP - "museum.pear.php.net"), link to that from the main package page at pear.php.net, and leave it like that (also, at the museum/graveyard remind people that PEAR can install packages from TGZs...). Problems would only start to arise if people actually try to install/upgrade these packages directly, but the site itself would indicate these are in the museum/graveyard, so confusion/breaks should be limited. As for advertising new APIs... Horde is not a direct "follow up" to PEAR, is it? That is a role for PEAR2 instead. Given that, I don't think advertising external packages will do any good to PEAR. Advertising PEAR2 equivalents, sure, but not external ones. Otherwise, a good number of other packages could also be dropped in favor of, let's say Zend. And not to mention that some are in Horde too (e.g. Mail... I personally use Zend_Mail, because I found its API both cleaner and more powerful than that of PEAR_Mail). There is already a page that advertises external PEAR channels... I think that's enough. From: Daniel O'Connor [mailto:daniel.oconnor@gmail.com] Sent: Thursday, November 10, 2011 1:46 AM To: Vasil Rangelov Cc: pear-dev@lists.php.net Subject: Re: [PEAR-DEV] Horde components, deprecating old pear compontent On Thu, Nov 10, 2011 at 1:14 AM, Vasil Rangelov <boen.robot@gmail.com> wrote: I think it's about time something like PHP's "museum" is created at PEAR, so that the "live" package list can be less cluttered with dead ones. What do you think? I'm a fan of this, but the community is a bit split. See http://pear.php.net/bugs/bug.php?id=17203 and http://old.nabble.com/Re%3 A--PEAR-QA--A-'graveyard'-for-packages---unloved-packages-p29589353.html  The biggest hurdle is the PEAR installer has no support for a package migrating channels - if the code vanishes from the PEAR channel; it breaks people's systems. I've been meaning to take a look at how hard it could be; but have never had the time really. We have deleted some content from SVN or from PEAR, but only when it's had ridiculously low downloads over 6 years or so and isn't installable at all. For the original email; I'd love to superceed any of the below which have drop in replacements in horde:  File_PDF  (lead)  Bugs  Log  (lead)  Bugs  Mail  (lead)  Bugs  Net_SMS  (lead)  Bugs  Net_SMTP  (lead)  Bugs  Net_Socket  (lead)  Bugs  SOAP  (lead, inactive)  Bugs  Text_Diff  (lead)  Bugs  VFS  (lead)  Bugs  XML_SVG  (lead, inactive)  Bugs .. plus blog a few migration tutorials if needed (Horde_Log for instance is quite different); and generally advertise the new APIs to the world. This puts us in the right direction for having a "PHP5 friendly" set of replacements, stops some of the perception that PEAR code is "crufty and old"; but still supports BC. Even better; it means that we'll see more PEAR / PEAR2 packages which use channels :)