On Wed, Jun 24, 2015 at 11:55:45AM +0200, Johannes Schauer wrote:
> Hi,
>
> On Wed, 24 Jun 2015 11:33:27 +0200 Martin Quinson <martin.quin...@loria.fr>
> wrote:
> > On Wed, Jun 24, 2015 at 11:09:47AM +0200, marivalen wrote:
> > > Using `GZIP=-9n cmake -E tar` does not work. It seems that cmake does not
> > > pass environment variables to the command it runs. This explains the
> > > introduction of the env cmake command.
> >
> > What about patching the cmake -E tar so that it understands (or even
> > apply by default) the -n flag itself? That would be the best so solve
> > a lot of reproducibility issues at once, isn't it?
>
> Making `cmake -E tar` understand the -n flag would not help because it would
> still mean that all packages using it would have to be patched to use it.
> Setting the environment variable GZIP=-n per default on the other hand might
> lead to unexpected output for sources that expect the old default behaviour to
> put timestamps into the gzip header.
>
> Searching for "${CMAKE_COMMAND} -E tar" or "cmake -E tar" on codesearch.d.n
> reveals that there are only 22 source packages that make use of this
> construct.
> So it might be easier to just patch these 22 than to change cmake upstream's
> default behaviour for "cmake -E tar".Ok, I was misestimating that, thanks for checking. I'll apply the debdiff and reupload, as well as trying to find a solution upstream. Thanks for your work on this very important issue, Mt. -- If you were plowing a field, which would you rather use? Two strong oxen or 1024 chickens? -- Seymour Cray
signature.asc
Description: Digital signature
