Re: Horde components, deprecating old pear compontent
| From: | till | Date: | Thu, 10 Nov 2011 14:21:56 +0000 |
| Subject: | Re: Horde components, deprecating old pear compontent | ||
| References: | 1 2 3 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-54575@lists.php.net to get a copy of this message | ||
On Thu, Nov 10, 2011 at 12:46 AM, Daniel O'Connor
<daniel.oconnor@gmail.com>wrote:
> 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%3A--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.
>
I'm wondering if we can leverage the info in pearweb. E.g. it already notes
that a package is superceeded or deprecated in favour of another package.
Isn't that pretty much the same? I mean, the channel (aka location)
shouldn't matter.
Till
>
>
> For the original email; I'd love to superceed any of the below which have
> drop in replacements in horde:
>
> - File_PDF <http://pear.php.net/package/File_PDF>
> (lead)
> Bugs<
>
> http://pear.php.net/bugs/search.php?package_name%5B%5D=File_PDF&cmd=display
> >
> - Log <http://pear.php.net/package/Log> (lead)
> Bugs<
>
> http://pear.php.net/bugs/search.php?package_name%5B%5D=Log&cmd=display>
> - Mail <http://pear.php.net/package/Mail> (lead)
> Bugs<
>
> http://pear.php.net/bugs/search.php?package_name%5B%5D=Mail&cmd=display>
> - Net_SMS <http://pear.php.net/package/Net_SMS> (lead)
> Bugs<
>
> http://pear.php.net/bugs/search.php?package_name%5B%5D=Net_SMS&cmd=display̗½½Æó¿‹r{è
> Þ
> >
> - Net_SMTP <http://pear.php.net/package/Net_SMTP>
> (lead)
> Bugs<
>
> http://pear.php.net/bugs/search.php?package_name%5B%5D=Net_SMTP&cmd=display
> >
> - Net_Socket <http://pear.php.net/package/Net_Socket> (lead)
> Bugs<
>
> http://pear.php.net/bugs/search.php?package_name%5B%5D=Net_Socket&cmd=display
> >
> - SOAP <http://pear.php.net/package/SOAP> (lead,
> inactive)
> Bugs<
>
> http://pear.php.net/bugs/search.php?package_name%5B%5D=SOAP&cmd=display>
> - Text_Diff <http://pear.php.net/package/Text_Diff>
> (lead)
> Bugs<
>
> http://pear.php.net/bugs/search.php?package_name%5B%5D=Text_Diff&cmd=display
> >
> - VFS <http://pear.php.net/package/VFS> (lead)
> Bugs<
>
> http://pear.php.net/bugs/search.php?package_name%5B%5D=VFS&cmd=display>
> - XML_SVG <http://pear.php.net/package/XML_SVG> (lead,
> inactive)
> Bugs<
>
> http://pear.php.net/bugs/search.php?package_name%5B%5D=XML_SVG&cmd=display
> >
>
> .. 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 :)
>