Re: php: museum.php.net is broken - change recipe SRC_URI?

[Boszormenyi Zoltan <zboszor@pr.hu>]

2014-11-03 17:08 keltezéssel, Bryan Evenson írta:
> Paul,
>
>> -----Original Message-----
>> From: Paul Eggleton [mailto:paul.eggleton@linux.intel.com]
>> Sent: Monday, November 03, 2014 10:46 AM
>> To: Bryan Evenson
>> Cc: Martin Jansa; koen@dominion.thruhere.net; openembedded-
>> devel@lists.openembedded.org
>> Subject: Re: [oe] php: museum.php.net is broken - change recipe SRC_URI?
>>
>> Hi Bryan,
>>
>> On Monday 03 November 2014 14:03:42 Bryan Evenson wrote:
>>> The official PHP archival version download site,
>>> http://museum.php.net, has been down at least since the beginning of
>>> October.  This is a problem for daisy and older branches if a build
>>> attempts to fetch PHP.  I expect this site will be back up again
>>> sometime, but from reading the conversation on the related PHP bug
>>> report (https://bugs.php.net/bug.php?id=68130) I do not believe
>>> http://museum.php.net can be viewed to be a reliable archive in the
>>> future.  I see that dizzy changed the SRC_URI to use
>>> http://www.php.net/distributions for the main download.  I did some
>>> testing and it appears that PHP versions that are about a year old or
>>> less are available from http://www.php.net/distributions.  So we can
>>> assume that a year from now the dizzy branch SRC_URI will need to change
>> to something else.
>>> I'd propose changing the SRC_URI to something that will not change
>>> over time.  My suggestion would be the PHP distributions Git
>>> repository located
>>> here: http://git.php.net/?p=web/php-distributions.git;a=summary.  This
>>> is the path suggested in the related PHP bug mentioned earlier.  The
>>> disadvantage is that the SRC_URI would refer to a file on a specific
>>> tag, so the SRC_URI would be specific for each PHP version.
>>>
>>> Any further suggestions on how to handle this?  If the SRC_URI does
>>> get updated, how many branches back should the change be made?
>> So we do have mirrors that can help with this, unfortunately with the OE
>> mirror (as opposed to the Yocto Project one), its population is not automatic,
>> so you have to request that new archives get added. I'm not sure it would be
>> practical to change this either.
>>
>> Why php thinks it's a good idea to distribute these tarballs in a single place in
>> a git repository but not in a simple flat HTTP location is a bit beyond me.
>> Fetching directly from git in this situation wouldn't be ideal as it'll end up
>> effectively fetching all of the binaries down when cloning the repo; however
>> I guess you could download a single file with:
>>
>> SRC_URI = "http://git.php.net/?p=web/php-distributions.git;a=blob;f=php-
>> ${PV}.tar.xz"
> Not exactly.  It looks like the old versions that are no longer supported get deleted from php-distributions.git, so HEAD doesn't have knowledge of all PHP versions.  For example, this link: http://git.php.net/?p=web/php-distributions.git;a=blob;f=php-5.4.22.tar.bz2 as of today will download php-5.4.22.  But this link: http://git.php.net/?p=web/php-distributions.git;a=blob;f=php-5.4.21.tar.bz2 just reports that it cannot find the file.
>
> As far as fetching php-5.4.14 (version used for daisy and older) I think this URL will work: http://git.php.net/?p=web/php-distributions.git;a=blob;f=php-5.4.14.tar.bz2;h=0d950f179d586bb1d0e879e0d4aa3a5140e8d5f5;hb=3dd2f12609fc8a730d7cf341a932f6c7b241f03c.  Ugly, but it works.

What's wrong with this?

SRC_URI =
"http://php.net/get/php-${PV}.tar.bz2/from/this/mirror;downloadfilename=php-${PV}.tar.bz2"

>
> Would it make more sense to start cloning the source Git repository at https://git.php.net/repository/php-src.git instead of the tarball?  It would download a lot more data, but at least we should be able to use a single SRC_URI for each minor PHP version.
>
> Regards,
> Bryan
>