On Mon, 2021-04-12 at 23:10 +0200, Lennart Poettering wrote: > Or in other words: packaging metadata are sources too. If they change > (and a version bump constitutes a change) the output might change, > and > that's expected. What's key really is that the only things that can > effect generated output are the build/packaging environment and the > sources, but not parameters outside of that, such as the actual > wallclock. The main way that packaging "interferes" with the source is when patches are applied - the original timestamp of a tarball (for example) isn't complete enough to use for $SOURCE_DATE_EPOCH. That's fair. > > > My concern centers around the Copy on Write (CoW) use case - when > > packages are updated, some files changes, and some may stay the > > same. > > Where they are the same, we can save I/O and possibly download time > > long term. > > Reproducible builds the way they are defined do not address such > file-level CoW optimization so much. They do address CoW optimization > on a package level much more however: i.e. the same package build > will > have the same files in them, no matter what. > > Or to say this differently: if you want reproducible to work the way > ou think it should work, you'd have to start by convincing the > uptream > maintainers to kill $SOURCE_DATE_EPOCH and similar concepts, but good > luck with that. 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. I remain concerned that this proposal forces the issue and for every single version of every single ELF binary *must* be different, even if they really didn't change. The pattern I see is more automation and faster, smaller release cycles, and this forcing downloads and writes of binaries that really didn't change their code. 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. This would work on images without rpmdb, works on most filesystem types, be serialized in archives. Most interestingly this could be implemented as an rpm plugin, and would work retroactively for packages that were built before this proposal. It could also be made to work for other packaging systems, and the tooling that reads it wouldn't need to know the original packaging system. Thoughts? Matthew _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
