Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101338
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain vdwaa.nl from 74.125.82.51 cause and error)
Date: Tue, 12 Dec 2017 21:50:14 +0100
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Message-ID: <20171212205013.yniwxasnvijcz5km@gmail.com>
References:<20171211211157.d7lj5vibpaaka4ji@gmail.com>
 <3aa774e4-c83b-79e1-edf8-acbbad76ea41@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To:<3aa774e4-c83b-79e1-edf8-acbbad76ea41@gmail.com>
User-Agent: NeoMutt/20171208
Subject: Re: [PHP-DEV] [RFC] Reproducible Builds Support
From: jelle@vdwaa.nl (Jelle van der Waa)

On 12/11/17 at 11:33pm, Stanislav Malyshev wrote:
> Hi!
> 
> > Once issue is the PHP_BUILD_DATE, which makes the build
> > non-reproducible. I've made a PR which uses SOURCE_DATE_EPOCH which is
> > set in the reprodiculbe build env. This should keep the current
> > functionality intact, while adding support for reproducible builds. [2]
> > [3]
> 
> SOURCE_DATE_EPOCH (or any other variable) looks like a good way to make
> it predictable.
> 
> > Another issue is the php_uname functions which contains the
> > hostname, since the hostname is varied per build this makes it
> > non-reproducible. This is caused by the following line:
> > 
> > configure.ac:PHP_UNAME=`uname -a | xargs` required in:
> > ext/standard/info.c:            php_uname = PHP_UNAME;
> 
> I think the best solution here would be to have another variable to
> override this.

The issue with this approach would be that every distribution has to set
this variable. I know it's the same with SOURCE_DATE_EPOCH, but that is
well established.
> 
> > I would argue that this is strange unexpected behaviour, and maybe it
> > should throw an exception instead? Or can it show only "Linux" as
> > fallback? basically PHP_OS. Ideas?
> 
> If those old systems run PHP and need uname, changing stuff there is
> probably harder and more expensive than on other systems. With this in
> mind, I'd rather not mess with it, especially for a purpose that can
> easily be achieved without it.

Hmmm true, but the fallback being the hostname where PHP was build on
seems a little bit odd, doesn't it?

-- 
Jelle van der Waa