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 <[email protected]> > > > > 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
