On Thu, Feb 27, 2020 at 03:44:48PM +0100, Alexander Dahl wrote: > Signed-off-by: Alexander Dahl <[email protected]> > --- > 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. | [email protected] | 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 [email protected]
