[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-tar] [PATCH] Add --clamp-mtime option

From: Jakob Bohm
Subject: Re: [Help-tar] [PATCH] Add --clamp-mtime option
Date: Tue, 09 Jun 2015 21:09:01 +0200
User-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

On 08/06/2015 23:26, Paul Eggert wrote:
On 06/08/2015 07:31 AM, Jakob Bohm wrote:
Backdating the compile output with touch may have a negative impact on
doing a make (not a full rebuild) while trying to fix a bug in the
package.  --clamp-mtime restricts the time stamp manipulation to the
contents of the .deb / .udeb / .tar.xz files .
Sorry, I'm still not getting it.  It seems to me that any method that
would have a negative impact on 'make' when using 'touch', would have a
similar negative impact in the generated tarball when using
--clamp-mtime.  Can you give a more complete example of the problem?

Point is that the tarballs and the build tree are used in different

- The tarballs (inside or outside .deb files) in the public repository
serve to provide the files to the end users in a way which causes the
least operational issues.  For example, files in /usr/share should have
the same binary contents and the same timestamps across architectures,
and thus across buildds.  As another example, unchanged files should
preferable keep their timestamps to reduce the size of date-based
incremental system backups.

- The build tree where the packages are generated serves the purpose of
doing this generation, mostly through invocations of make.  This
depends heavily on the invariant that "output file newer than input

Using tar command line options to normalize the timestamps inside the
archives allows preserving the make-needed properties in the build
tree, but the user-needed properties in the packages.

The proposed --clamp-mtime option provides a refinement of the
existing --mtime option in that the "virtual touch" will only move
timestamps backwards in time, not forwards.

So if the tree was created with commands such as (presumably in
makefiles, often via debhelper scripts, grossly simplified for

  gcc -O2 -o foo foo.c
  cp -p foo foo.debug
  sstrip foo
  cp -p foo debian/foo/usr/bin/foo
  cp -p foo.debug debian/foo-debug/usr/bin/foo.debug
  cp -p foo.conf.sample debian/foo/etc/foo.conf
  cp -p doc/foo.1 debian/foo/usr/share/man/man1/foo.1
  gzip -9 -n debian/foo/usr/share/man/man1/foo.1
  cp -p debian/changelog \
  ln -s foo debian/foo-debug/usr/share/doc/foo-debug
  dpkg-invoked-tar -C debian/foo -o debian/tmp/data.tar \
     --mtime $(dpkg-parsechangelog | grep '^Date:' | cut -c 6-) \
  dpkg-invoked-tar -C debian/foo-debug -o debian/tmp/data.tar \
     --mtime $(dpkg-parsechangelog | grep '^Date:' | cut -c 6-) \

Then in the resulting .deb files, the man page
will have the timestamp of "doc/foo.1" from the source package, while
the freshly compiled files /usr/bin/foo and /usr/bin/foo.debug would
have the timestamp listed in the changelog.  The installed Debian
changelog will also have the timestamp listed inside it, not the
timestamp (a few seconds later) when the maintainer saved it from hir
editor. The conffile /etc/foo.conf will only change its timestamp when the default in the source package changes, thus making life easier for
end users everywhere.

At the same time, make will still see the files in debian/foo with the
timestamps make expects, and will thus not redo most of the copies and
compilations, as it would if the actual files had been backdated with
touch.  This speeds up some complex package builds on the buildds, and
much more importantly speeds up local builds on the maintainer's
own machine.


Jakob Bohm, CIO, Partner, WiseMo A/S.
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

reply via email to

[Prev in Thread] Current Thread [Next in Thread]