On Fri 2015-02-13 14:33:12 -0500, Paul Gevers wrote: > On 13-02-15 18:28, Reproducible builds folks wrote: >> If you want to help, a first step is to check the reproducibility of >> your packages [DDLIST]. Feel free to ask for help on the >> <firstname.lastname@example.org> mailing list or in >> #debian-reproducible on irc.debian.org. > > It would help me if you would have mentioned here what you expect people > to do when their package is not reproducible, but when this is the > result of other packages that they use during building. I am not going > to fix my packages if e.g. the timestamp in the documentation is > inserted by the use of formatXtoFormatY, we should then rather focus on > fixing formatXtoFormatY. I believe you agree. If people all start fixing > such issues inside their own package than in some time we have all kind > of solutions, which may (or may not) bit-rot and may not be needed if we > fix formatXtoFormatY.
Some of these tools have legitimate reasons in non-reproducible environments to inject timestamps. Even in reproducible environments, it can be useful to inject a timestamp (a known, static one like the value in debian/changelog) in things like generated man pages. This means we should encourage formatXtoFormatY tools to make it easy to expose no-timestamp and/or externally-provided-timestamp modes of operation, and we should certainly encourage package-building frameworks like dh to set those modes by default. The less information we have to encode (and maintain) in every single debian/rules or debian/control file, the better. However, for packages that don't use a framework we can fix, or which use a tool that has no plans to adopt these kinds of modes upstream, having the deviations embedded in our packaging files is the only thing to do if we want reproducible builds. It would be a shame if we had to wait for every format-converter to get upgraded to do the right thing automatically to get debian itself to a reproducible state. Your concerns about bit-rot are legitimate, though; if a piece of the toolchain is where a "proper" fix belongs, and all the dependent packages are working around it now, perhaps we could (a) make sure that the "proper fix" bug report is filed in the bts against the piece of the toolchain, and that it is marked as "affects:" with all the packages that are currently working around it. If a package is doing a workaround that it shouldn't need to do, we could even file a wishlist bug against that package and mark it as blocked by the toolchain bug. Basically, i think the BTS has the semantics to support keeping track of these dependent issues so that we end up with clean long-term fixes, while we can use our packager's discretion to implement the shorter-term workarounds, annoying though they may be. what do you think? --dkg _______________________________________________ Reproducible-builds mailing list Reproducibleemail@example.com http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds