[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