[pacman-dev] [PATCH] makepkg: introduce SOURCE_DATE_EPOCH

[Andrew Gregory]

On 04/17/17 at 03:53pm, Levente Polyak wrote:
> On 04/17/2017 03:34 PM, Andrew Gregory wrote:
> > On 04/17/17 at 08:41pm, Allan McRae wrote:
> >> This patch introduces the SOURCE_DATE_EPOCH environmental variable.  All files
> >> in a package are adjusted to have their modification dates set to the value
> >> of SOURCE_DATE_EPOCH, which defaults to "date +%s".
> >>
> >> Setting this variable allows a package that is built twice in the same
> >> environment to be (potentially) reproducible in that the checksum of the
> >> generated package file will be the same.
> >>
> >> Signed-off-by: Allan McRae <allan at archlinux.org>
> > 
> > I'm of the opinion that makepkg is the wrong place to work on
> > reproducible builds.  We could probably take care of the low-hanging
> > fruit directly in makepkg, but a number of packages are going to
> > require more find-grained control over the environment then I think we
> > should be putting in makepkg.  If you look at `perl -V`, for instance,
> > it embeds the output of `uname -a` and a timestamp directly in the
> > executable.  I suspect that any effort we put into reproducible builds
> > with makepkg would eventually have to be duplicated with a more
> > powerful wrapper script in order to handle packages like perl that
> > record more of their environment than we should be manipulating in
> > makepkg.
> > 
> > apg
> > 
> 
> Makepkg is the place that we control and need to work on to make
> packages created by makepkg reproducible. Currently they are not exactly
> because of the reasons these patches address and there is literally no
> way to get reproducible package artifacts without these patches.
> Especially the deterministic way to pass in SOURCE_DATE_EPOCH is a
> requirement for cases you mentioned and downstream projects using dates
> in any produced artifacts should implement SOURCE_DATE_EPOCH. An
> incredible high amount of projects already do so and more and more adopt
> as this is getting infacto a standard (actually it already is).
> No complex wrapper scripts should be needed at any place to achieve
> reproducibility.
> 
> cheers,
> Levente

I have no problem with making makepkg's own output more controllable
(e.g.  allowing builddate to be set rather than using the current
time).  But, a lot of the time, reproducing an identical package is
going to require a very precise environment, especially for compiled
software.  The environmental factors that influence the built software
vary from project to project and can get their values from a variety
of locations.  I think that trying to manage all of that from makepkg
would be a mistake if it would even be possible.  Some things, like
building in a chroot for software that embeds the build directory,
would almost certainly be easier from a script that wraps makepkg.
I would prefer to see effort be put toward such a script rather than
have it go into makepkg only to have to be moved to a separate script
later.

apg