Re: [RFC] Reproducible Builds Support
| From: | Jelle van der Waa | Date: | Tue, 12 Dec 2017 20:50:14 +0000 |
| Subject: | Re: [RFC] Reproducible Builds Support | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-101338@lists.php.net to get a copy of this message | ||
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