I would like to know if there is any conceivable way to do independent reproducible builds of the ports tree packages today?
The biggest obstacle seems to be the fact that FreeBSD does not have a snapshot/archive repo equivalent to snapshot.debian.org.
My current approach is to fetch the .pkg, extract the ports_top_git_hash metadata, checkout the ports tree to that commit and run e.g. poudriere
bulk -j "$JAIL" -p "$PORTS_TREE" "$ORIGIN"
But I am not sure how poudriere handles changes in port tree commit
hash. If a next package comes in with a different ports_top_git_hash,
will poudriere be able to reuse any common dependencies that were
already built or will it have to rebuild the whole tree again?
The latter scenario is obviously a huge resource waste and an automatic no.
My first question is whether my approach is generally sound for trying
to reproduce a single package? If not, how should I correct my workflow?
My second one is for any workarounds or "close enough" techniques that
would at least be able to reproduce some amount of packages. I'd be
happy even with 10% reproducibility.
If I can find some path forward, I'd like to ultimately add FreeBSD
support to rebuilderd, a cross-distro effort to make distro packages independently reproducible.
Unless I'm missing something, wouldn't using poudriere with the same make.conf as the package builders and default options from the same
git build give *functionally* identical packages?
I don't have a need for identical packages but I find it useful and
elegant to check the git build level being used by the package
builders, checkout the same build then build my few packages and dependencies locally. That way I get my options included in my
packages where necessary but the rest of the packages are unaffected.
Doing this for the whole tree with default options throughout should
get the OP what he needs. Yes? Or have I misunderstood what is needed?
On 10 Nov 2025, at 09:05, Tatsuki Makino <tatsuki_makino@hotmail.com> wrote: However, if the reason curl is being rebuilt is due to an upgrade of the it depends on, then rebuilding only ftp/curl can avoid rebuilding rust.Hi,
cen wrote:
The goal is bit-for-bit reproducibility, "functionally" is not enough.
This is completely impossible for any operating system package
distribution. "Functionally" is the best you can get.
Ah, I see, so it was a topic in that direction :)
ELF format itself doesn't, by default, include information such as the compilation timestamp, maybe.
Even code that uses preprocessor __DATE__ and __TIME__ won't be reproducible unless we stop the clock, maybe.
At the very least, we can't make the parts involving such times match perfectly, can we? :)
Regards.
On 2025/11/11 4:53, Charlie Li wrote:
cen wrote:
The goal is bit-for-bit reproducibility, "functionally" is not enough.This is completely impossible for any operating system package distribution. "Functionally" is the best you can get.
Consider that Python ports built under some CPython (ie Python from python dot org) almost always
=20.
Kurt Jaeger wrote:
Hi!
cen wrote:
The goal is bit-for-bit reproducibility, "functionally" is not enough=
achieved it, and they admit it as such: https://wiki.debian.org/Reproducibl= eBuildsThis is completely impossible for any operating system package
distribution. "Functionally" is the best you can get.
Debian does it, so it does not seem to be out of the realm of
the possible.
They have efforts towards the goal, but it is a stretch to say they have =
=20
--=20
Charlie Li
...nope, still don't have an exit line.
=20
=20
=20
=20
This is completely impossible for any operating system package
distribution. "Functionally" is the best you can get.
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 59 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 04:04:37 |
| Calls: | 810 |
| Files: | 1,287 |
| D/L today: |
5 files (10,057K bytes) |
| Messages: | 203,128 |