Re: [ptxdist] [PATCH 2/3] os-release: Make date string reproducible

[Roland Hieber <rhi@pengutronix.de>]

On Thu, Feb 27, 2020 at 03:44:48PM +0100, Alexander Dahl wrote:
> Signed-off-by: Alexander Dahl <ada@thorsis.com>
> ---
>  rules/os-release.make | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/rules/os-release.make b/rules/os-release.make
> index 5156156a0..ba607aa38 100644
> --- a/rules/os-release.make
> +++ b/rules/os-release.make
> @@ -56,7 +56,7 @@ $(STATEDIR)/os-release.targetinstall: $(PTXDIST_PTXCONFIG) $(PTXDIST_PLATFORMCON
>  		@PTXDIST_VERSION@, $(PTXDIST_VERSION_FULL))
>  
>  	@$(call install_replace, os-release, /usr/lib/os-release, \
> -		@DATE@, $(shell date +%FT%T%z))
> +		@DATE@, $(shell date --utc --date @$(SOURCE_DATE_EPOCH) '+%FT%T%z'))

This sets PTXDIST_BUILD_DATE. I think SOURCE_DATE_EPOCH was not used
here deliberately, otherwise the date would always be the same, and
what's the use of the variable then?

Which leads to the question: why is there a date at all here, and what
useful additional information does it provide? The only thing I've come
up with so far is that it acts as a monotonically increasing version
number for the image, so you can compare images in terms of recency.
Therefore this date should be as new as possible. On the other hand it
should be also as stable as possible for reproducibility. So I think we
should rather set the build date to the modification time of the newest
source file in the BSP. We could do that by defining a variable in
scripts/lib/ the same manner as PTXDIST_BSP_AUTOVERSION.

Same goes for /etc/issue in your next patch.

 - Roland

-- 
Roland Hieber, Pengutronix e.K.          | r.hieber@pengutronix.de     |
Steuerwalder Str. 21                     | https://www.pengutronix.de/ |
31137 Hildesheim, Germany                | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686         | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de