Re: [PATCH] Help Ruby packages be reproducible

[Ricardo Wurmus]

Ben Woodcroft <address@hidden> writes:

> On 31/12/15 03:26, Ludovic Courtès wrote:
>> Ben Woodcroft <address@hidden> skribis:
>>
>>> On 29/12/15 15:46, Ben Woodcroft wrote:
>>>> Unfortunately none of these builds are reproducible because rubygems
>>>> in Guix generally aren't. For one, this is because .gem files are
>>>> archives whose contents are timestamped.
>>> I should clarify. What I meant was the cache .gem files
>>>
>>> /gnu/store/ib83mg5zsyr5x2w0m3i1f84gdvdbp5x9-ruby-ascii85-1.0.2/lib/ruby/gems/2.2.0/cache$
>>> tar tvf Ascii85-1.0.2.gem |head
>>> -r--r--r-- wheel/wheel     703 2015-12-27 22:44 metadata.gz
>>> -r--r--r-- wheel/wheel    7436 2015-12-27 22:44 data.tar.gz
>>> -r--r--r-- wheel/wheel     268 2015-12-27 22:44 checksums.yaml.gz
>> We should arrange so that gems are created with a fixed timestamp and
>> UID/GID, and a well-defined file ordering, as with:
>>
>>    address@hidden --sort=name --owner=root:0 --group=root:0
>>
>> We also need to make sure gzip is always run with -n/--no-name.  That
>> way, the gz files above will not include an additional timestamp.
>>
>>  From what I can see in
>> <git://git.debian.org/git/reproducible/notes.git>, this is not addressed
>> yet in other distros.
> Ludo are you suggesting we should abandon the deletion approach?

Abandoning the deletion approach only makes sense if we have control
over the way “gem” packages up archives.  As far as I remember “gem”
archives are actually regular tarballs with some additional metadata.
The “gem” command itself does not expose any means by which we could
control the mtime of the archive contents.

As the “.gem” file itself is likely redundant I don’t see a problem
removing it as you proposed.

@Dave: what do you think about just removing the cached “.gem”?

> I think you are right as usual. Better in attached?

It looks good to me, thank you.

~~ Ricardo