The idea of faking this and that (timestamps, builder hostname, ... whatever) is weird. It always leads to a question: why do we even have / use such metadata, if we fake them anyway? Only either ditching such values entirely or always honoring them does make sense to me. Or inventing new ones that better fit the various use cases we have (like before mentioned splitting metadata from artifacts and so on) But if your proposal is the best we have, I'm fine with it. It's your time after all :) and I haven't noticed it would affect me (or rather "make my life harder") in any way both as a user and as a package maintainer. -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Sat, Nov 26, 2022 at 11:09 PM Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx> wrote: > > On Fri, Nov 11, 2022 at 10:14:56AM -0500, Neal Gompa wrote: > > On Fri, Nov 11, 2022 at 8:46 AM Clemens Lang <cllang@xxxxxxxxxx> wrote: > > > > > > Hi, > > > > > > Alexander Sosedkin <asosedkin@xxxxxxxxxx> wrote: > > > > > > > In RPM world, I've even entertained an idea of having a subpackage for > > > > auditability not unlike how we have debuginfo, since rebuilding a package > > > > reproducibly requires builddep pinning. But if that's avoidable, I’d > > > > rather just not mix artifacts with meta. > > > > > > Debian is working on this already, they call those “buildinfo” files: > > > > > > https://wiki.debian.org/ReproducibleBuilds/BuildinfoFiles > > > https://manpages.debian.org/testing/dpkg-dev/deb-buildinfo.5.en.html > > > > > > If we want something similar, I’d propose not to completely re-invent the > > > wheel. > > > > > > > We've discussed an RPM-specific format upstream. Debian and Arch both > > have their own formats that are tailored to their package systems, and > > RPM may have one too, eventually. > > For context, the discussion is here: > https://github.com/rpm-software-management/rpm/pull/1532 > > -- > Best Regards, > Marek Marczykowski-Górecki > Invisible Things Lab > _______________________________________________ > 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, report it: https://pagure.io/fedora-infrastructure/new_issue _______________________________________________ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
