On Mon, Apr 12, 2021, at 8:44 PM, Matthew Almond via devel wrote:
I think we should be careful to de-couple these two things. Just
because $SOURCE_DATE_EPOCH is likely to affect a lot of binaries is not
proof that all binaries will.
Agreed; it'd be interesting to gather some data here, particularly components with
large binaries.
I have just thought of an alternative proposition: for ELF objects
(and
ELF objects only): rpm could automatically, and systematically record
the metadata in an xattr.
OSTree would be affected in the same way as your "RPM CoW" proposal by the
approach of having it in the binary directly. Unless we did this, because ostree is based
on hardlinking which works on every filesystem, but shares an inode and hence the extended
attributes are included in the ostree checksum. (There is some support for adding an
additional "payload" i.e. content checksum in ostree but it adds another mapping
and so we don't enable it by default).
But on reflink-capable filesystems in theory if this content is just in the ELF header we
could skip it and reflink just the remainder which would be most of the binary. (But,
this would necessitate a strategy other than checksumming the whole binary of course,
something more like rsync-style "rollsum" windows that we use for ostree static
deltas, e.g.)