Pass an optional mtime param to HeaderMode::Deterministic

[e-nomem]

This mtime value will be used instead of DETERMINISTIC_TIMESTAMP when provided. This is useful e.g. to pass in $SOURCE_DATE_EPOCH to support reproducible builds.

This is a breaking change. Given that HeaderMode is marked as non_exhaustive, it is possible to make this a non-breaking change by adding a new mode variant that uses the mtime override instead.

[xzfc]

This is a breaking change. Given that HeaderMode is marked as non_exhaustive, it is possible to make this a non-breaking change by adding a new mode variant that uses the mtime override instead.

Breaking is not desirable. A new variant would be fine.

This mtime value will be used instead of DETERMINISTIC_TIMESTAMP when provided. This is useful e.g. to pass in $SOURCE_DATE_EPOCH to support reproducible builds.

The overall idea is LGTM.

[xzfc]

There are multiple feature requests to extend HeaderMode:

• Specify particular timestamp.
  • (this PR) Pass an optional mtime param to HeaderMode::Deterministic #424
  • Add a force_mtime() function to allow overriding all mtime fields #337
• Preserve all supported metadata, but clamp too new timestamps (--clamp-mtime).
  • support equivalent to tar's --clamp-mtime #409
• Preserve timestamps but not usernames.
  • Please support a Mode that preserves timestamps but not usernames #339
• Maybe others.

Maybe these and similar cases could be covered by a new enum variant with a single non_exhaustive struct field.

[e-nomem]

I added a new HeaderMode::Override variant that has non-exhaustive struct with individual field overrides. AFAICT the design addresses the use cases from all the linked issues.

It feels a touch verbose but one of the upsides is that both HeaderMode::Complete and HeaderMode::Deterministic can be expressed as overrides so it does unify the HeaderMode handling logic a bit.