Hi! On Fri, 2013-08-16 at 08:45:47 -0400, Asheesh Laroia wrote: > On Fri, 16 Aug 2013, Guillem Jover wrote: > >The same will apply when building that deb package multiple times, > >the timestamps will change for the ar headers. And I don't really > >want to lose that data, because currently is the only place were > >the build time information is recorded. Do you only care that the > >members themselves are deterministic or the whole deb package? > > > >I think I'd be fine with not storing the timestamps in the > >compressed members themselves, but not about the ar container.
> I would prefer to keep even the 'ar' container free of those > timestamps, but there are some workarounds I can imagine if you > don't want to do that for now. > > We could perhaps let 'dpkg' accept an argument to set that > timestamp, and/or we could use 'faketime' when trying to reproduce a > build, if we know what timestamp to reproduce. (My notion here is > that it should be easy for someone to create the same bits that we > publish in Debian, even if that reproducing effort is slightly > different than just doing a fresh build.) > > Another way that we could do it is to store the last > debian/changelog timestamp in the ar header. That would be my > favorite approach. I've been thinking about this, and I think you might be trying to solve the problem in the wrong place(s), and possibly there's a need to step back and ponder about what do you really want out of all this, to know where or how to best fix it. The way I see it (and that I think you guys have maybe intermingled) is that there's different types of changing information: There's accidental changing information leaks, stuff like usernames, hostnames, timezone, output or sorting order depending on locale, data dependant on random input like signatures or similar, etc, which might just need fixing anyway because they leak information from the builder, or should ideally be generated on the installed system. Then there's possibly redundant changing information, like _some_ timestamps on filenames, versions, or even metadata. And then there's changing information that conveys important data. For example, in the generated data.tar the files will contain different modification times, some will come untouched from the source files if they just get copied, and others will be newer if the files got created at build time. Preserving these timestamps seems important to me, because you then know the possible staleness of the files. The timestamp on the ar member let's you know when the package got built. Possible future ar members containing gpg signatures from the builder or the archive, would change and not be reproducible anyway. The recent switch of dpkg-deb default compressor. Or possible future .deb format revisions. Etc. So my question is, what's really the stuff you'd like to know has not changed. Just file paths, contents and permissions for example. That seems extremely reasonable w/o dropping possibly important information, or getting us stuck in possibly old formats and similar. Would there be something else? Depending on that, maybe instead of dropping some of the information, we might just need a way to for example easily compare .deb files, ignoring unimportant changing data, ala «dpkg-deb --compare a.deb b.deb» or something along those lines or some other new program. Thanks, Guillem -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
