Hi! On Thu, 2014-08-28 at 12:35:56 -0700, Niko Tyni wrote: > On Wed, Aug 27, 2014 at 11:31:16AM +0200, Guillem Jover wrote: > > On Tue, 2014-08-26 at 17:51:22 -0700, Niko Tyni wrote: > > > > I can see that this could cause timestamp skew in packages if the Debian > > > packaging is older than files in the upstream tarball. This seems like > > > it's always a (minor) bug in the package, and dpkg-source could probably > > > notice that it's "rewinding" the time stamp backward and fall back to > > > using the current time instead. > > > > The problem is that I don't see how dpkg-source can always tell if > > it's “rewinding” in such case, it could tell if the new timestamp is > > older than the current one, but it might not be able to tell if the > > new timestamp is older than one from a file that depends (in make > > terms) on this file for example. > > In the scope of just the source package, it seems possible for dpkg-source > to remember the latest timestamp it has extracted and notice if that's > newer than the debian/changelog timestamp. Are you thinking about files > in other packages too? I suppose it's possible that package builds are > relying on timestamps of files in their build dependencies even though > that does seem rather fragile to me.
I was thinking about in-tree generated files or objects. Those will have a current time, but if the patched files do always have a time matching the one from debian/changelog, then the time comparisons make(1) does cannot work anymore. For example consider the following scenario: * Unpack source package (all patches applied). $ dpkg-source -x foo.dsc * Build the source. $ dpkg-buildpackage -us -uc * Pop one or several patches, modify one patch in the middle. $ quilt pop 3 $ quilt edit foo/bar.c $ quilt refresh * Rebuild, w/o clean (applies missing patches). $ dpkg-buildpackage -us -uc -nc now make(1) cannot tell if the files need to be updated or not. So it's not just “broken” time from upstreams, it's also usual interactions between patched and generated files. Or what about people that keep patches already applied in their git tree? git always updates file timestamps on checkout, so that would also cause variable output with your problem, when rebuilding directly from a git tree. > > This also gets more complicated when dealing with NFS mounts, which > > the current code is already handling correctly. > > Could you elaborate a bit on that? Is there some NFS specific code in > dpkg-source at the moment? Because dpkg-source cannot know the time of the NFS server, it needs to “touch” files and check their stat data to get the remote time, and then set the same “remote current time” for all files in a patch. This also relates to how the patched and generated files interact. > > Although some of these situations might show up from timestamp skews > > due to mismatched times from upstream, packager, or build systems for > > example, that's just a reality that I'm not sure we can ignore. > > Yeah, I see it's complicated. > Do you think an archive-wide check for source packages having newer > files than their debian/changelog timestamps might tip the scales, or > is it clear that this is just not going to work? (I guess lintian would > be a good place for such a check.) The more I think about this, the more I'm getting the impression this does not sound like a good idea. As mentioned initially, I think it would be better to possibly fix any tool that might be generating such variable files instead. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
