On Wed, Aug 8, 2018 at 5:50 AM Roland Hieber <r.hieber@pengutronix.de> wrote:
On Fri, Aug 03, 2018 at 11:44:55AM -0400, jon@ringle.org wrote:
> From: Jon Ringle <jringle@gridpoint.com>
>
> libfaketime will be used during patchin so that committer timestamps always
> have a fixed value and therefore making the ${PKG}_SERIES_SHA256 value
> repeatable
>
> The minimal set of source files was picked out of libfaketime-0.9.7
>
> Signed-off-by: Jon Ringle <jringle@gridpoint.com>
> ---
>  Makefile.in                           |   14 +-
>  scripts/libfaketime/Makefile          |  118 ++
>  scripts/libfaketime/faketime.c        |  385 ++++++
>  scripts/libfaketime/faketime_common.h |   61 +
>  scripts/libfaketime/libfaketime.c     | 2410 +++++++++++++++++++++++++++++++++
>  scripts/libfaketime/libfaketime.map   |   10 +
>  scripts/libfaketime/time_ops.h        |  104 ++

Uh. Does it really make more sense to vendor libfaketime instead of
using the package from the host system, like we do it with python, bash,
etc.?

The reason that this is needed as a core component of ptxdist rather than just being built as a host package is that patchin step uses libfaketime and therefore is potentially needed before even a single package is ever built. What would happen if we just used a host-libfaketime package and someone adds a patch series for libfaketime? (In fact, I actually do have such a patch series locally that I will be sending to the ptxdist ml later). This is a chicken vs egg problem that is resolved by making libfaketime an integral part of ptxdist. The ptxdist usage of libfaketime in the patchin step does not need a patched version of libfaketime (it just needs to set an absolute date time and the libfaketime code I have here does that). It doesn’t need new configuration features or bug fixes for fixing the time manipulation via some specific system call.

-Jon