Packages are not reproducible

[bdrewery]

#1829 got me thinking about this.

For Poudriere to not rebuild packages when there's no PORTREVISION bump to change the deps{version} means the naive way of repackaging them will always change the hash.

Stepping back from Poudriere the problem is that building the same port twice without any changes to the port can produce a different package metadata/deps and hash due to dep versions. I think framing the issue as a reproducibility problem might be clearer.

I would prefer to find a way to do what we need with Poudriere without changing hashes.

Things that care about the version:

1. pkg rquery %v
2. pkg add deps (ports depends on this)

My only idea currently is to make both assume the latest version which isn't great considering actually supporting multiple versions of packages in 1 repository with proper dependencies.

[bdrewery]

My only other thought is that we should map the *_DEPENDS into proper requires which could fix both problems with additional overhead in each command to process the full package set to solve versions.

[bdrewery]

Summary of IRC discussion:

Pkg

• Remove version from deps in packages
• Deprecate pkg query %dv (specifically the v)

Poudriere

• Continue to recursively delete package deps that have a version field to get them to rebuild in the new format
• Poudriere will not recursively delete (with the feature enabled in case someone doesn't trust PORTREVISION bumps) if the package has no versions in its deps.
• For sanity_check_pkg (only used for old packages and if feature disabled). For finding the right dependency for these decisions it will use the same logic as Mk/Scripts/do-depends.sh does. It just picks the package-version of what the port advertises it wants. I think there's a flaw in the sanity_check_pkg plan but it'll be worked out in testing.

[valpackett]

Remove version from deps in packages

That would be very nice, how's it coming along?

I just made a patch that adds a flag to ignore these versions: https://github.com/myfreeweb/pkg/commit/884c2e365e2cea7903b4e5fcf11f75cbd42a6834 and only then found this issue with the plan to remove them.

[bdrewery]

PKG_NO_VERSION_FOR_DEPS

[ghost]

When I run make package, my package's checksum is different even though the contents are identical. Is there a good way around that?

[michael-o]

When I run make package, my package's checksum is different even though the contents are identical. Is there a good way around that?

Well, this is a very long way to go. As a Maven PMC member I was involved to make all Maven-generated builds fully reproducible with the same JDK and system type (Windows xor POSIX-like). It took us years to address all components. (do not feel discouraged)

These are key points:

• Files in the tarball need to be reproducible, stable sorting JSON arrays, no dates, times, local paths. LLVM supports that, don't know about other languages.
• Order of tarball entried must be sorted stable
• Timestamps in tarball must be stable
• etc.

Use diffoscope(1) to analyze.

I'd be happy to consult.

[bapt]

We know how to make reproducible builds, I have been involved in the 2 first reproducible builds summit long ago. pkg per se is able to create reproducible package for around 5 years, the problem which is pointed out here is freebsd specific. (and thanks for pointing out at diffoscope, I am an early contributor of it, in particular porting it to freebsd, so I am well aware of it).

[michael-o]

We know how to make reproducible builds, I have been involved in the 2 first reproducible builds summit long ago. pkg per se is able to create reproducible package for around 5 years, the problem which is pointed out here is freebsd specific. (and thanks for pointing out at diffoscope, I am an early contributor of it, in particular porting it to freebsd, so I am well aware of it).

So this s a lack of resources rather than tooling?

PS: Thanks for diffoscope, I love it.

[bapt]

pkg can make reproducible packages just fine, pkg cannot make reproducible packages without breaking many existing tooling available in freebsd, so the issue is deal with the legacy