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.

[xzfc]

I've cleaned these changes up and published here: https://github.com/xzfc/tar-rs/commits/header-mode-config/

Tho I'm baffled that adding this enum variant can be considered a breaking change (as cargo semver-checks complains). I.e. after this change,

 #[non_exhaustive]
 pub enum HeaderMode {
     Complete,
     Deterministic,
+    Config(HeaderModeConfig), // breaking change!
 }

the following code no longer compiles:

// error[E0605]: non-primitive cast: `Enum` as `i32`
let x = HeaderMode::Complete as i32;
//      ^^^^^^^^^^^^^^^^^^^^^^^^^^^ an `as` expression can be used to convert
//                                  enum types to numeric types only if the
//                                  enum type is unit-only or field-less