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

[Jakob Bohm]

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
ways:

- 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
file".

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
illustration):

  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 \
     debian/foo/usr/share/doc/foo/changelog.Debian
  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-) \
     --clamp-mtime
  dpkg-invoked-tar -C debian/foo-debug -o debian/tmp/data.tar \
     --mtime $(dpkg-parsechangelog | grep '^Date:' | cut -c 6-) \
     --clamp-mtime

Then in the resulting .deb files, the man page
   /usr/share/man/man1/foo.1.gz
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.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
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