Hi, Quoting Ximin Luo (2016-11-10 18:13:00) > Holger Levsen wrote: > > On Thu, Nov 10, 2016 at 08:59:48AM -0200, Johannes Schauer wrote: > > > One solution would be to increase SOURCE_DATE_EPOCH by 1 second for every > > > binNMU to a package. > > > > > > Any other ideas? > > set SOURCE_DATE_EPOCH to the creation time of that changelog.$arch > > entry? > I'm tending towards the latter suggestion because it's simpler. There's no > need to stick to a +1 second scheme etc, and it might mislead people into > thinking they can do calculations with this - such as reversing the original > timestamp of the sourceful-upload.
maybe I'm misunderstanding the problem but for the sake getting a better picture, let me write a summary of the conversation so far: Currently, buildds (using sbuild) create binNMU changelog entries by copying the date from the last changelog entry. See for example libghc-yesod-auth-oauth-dev. 16 binNMUs and the same timestamp is used for all of them. In his original post, Ian complains that despite the package version being incremented, the file mtimes are not. This is because we now use the timestamp from the latest changelog entry for the mtimes of the binary package contents so that the binary packages become reproducible. If we want to have later mtimes for the files in binNMU binary packages compared the ones in the last version, then the question becomes: which mechanism should we use to set this timestamp? I do not think that reproducibility is an issue here. No matter which mechanism we choose to determine the timestamp of the new changelog entry, that timestamp will be recorded in the Binary-Only-Changes field of the generated .buildinfo file. The content of that field can then be used by package builders to generate the new debian/changelog which in turn means that at the time that dpkg-buildpackage is run, SOURCE_DATE_EPOCH will be set to a deterministic value: the value of the last changelog entry which we obtain from the Binary-Only-Changes field. Back to the question of how we should determine the initial timestamp for the new binNMU. One way would be to just use the timestamp of the time at which the binNMU changelog entry is created by sbuild on the buildds. The problem with this approach is, that binNMUs will be done at slightly different times on each architecture and thus a different changelog timestamp will be used per architecture. This does not cause Multi-Arch:same file conflicts because of the changelog itself because these are stored in architecture-specific paths for binNMUs (if dh_installchangelogs is used). Instead, file conflicts might be created from files with content that depends on SOURCE_DATE_EPOCH. Because each architecture will generate their own timestamp, SOURCE_DATE_EPOCH will be different on each. If the content of shared files depends on the set timestamp, then these packages will not be co-installable anymore. One solultion to this problem would be to mandate that files shared across Multi-Arch:same binary packages must be independent of SOURCE_DATE_EPOCH but that might impose too much of a burden of writing and then maintaining the appropriate patches for upstreams that refuse to become independent of SOURCE_DATE_EPOCH. Moving the architecture-invariant but SOURCE_DATE_EPOCH dependent files to Architecture:all packages is not a solution either because we might want the packages containing these files be able to transport their architecture to their dependencies. Thus I think it would be best if the changelog timestamp for the same binNMU version would be equal across all architectures. One way to achieve this would be by using a unified scheme to generate the timestamps, for example by incrementing the original timestamp by one second for each binNMU. Another way to achieve this would be to require a timestamp to be supplied (or generated) every time a binNMU is scheduled. That timestamp would then be passed to all buildds and be used by sbuild to generate the new entry in debian/changelog. What do you think? Thanks! cheers, josch
signature.asc
Description: signature
