[oe] php: museum.php.net is broken - change recipe SRC_URI?
Bryan Evenson
bevenson at melinkcorp.com
Mon Nov 3 16:08:37 UTC 2014
Paul,
> -----Original Message-----
> From: Paul Eggleton [mailto:paul.eggleton at linux.intel.com]
> Sent: Monday, November 03, 2014 10:46 AM
> To: Bryan Evenson
> Cc: Martin Jansa; koen at dominion.thruhere.net; openembedded-
> devel at 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.
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
More information about the Openembedded-devel
mailing list