Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Packages are not reproducible #1831

Open
bdrewery opened this issue Apr 13, 2020 · 9 comments
Open

Packages are not reproducible #1831

bdrewery opened this issue Apr 13, 2020 · 9 comments

Comments

@bdrewery
Copy link
Member

bdrewery commented Apr 13, 2020

#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
Copy link
Member Author

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
Copy link
Member Author

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
Copy link
Contributor

valpackett commented Dec 5, 2020

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: valpackett@884c2e3 and only then found this issue with the plan to remove them.

@bdrewery
Copy link
Member Author

PKG_NO_VERSION_FOR_DEPS

@ghost
Copy link

ghost commented Feb 23, 2022

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
Copy link
Contributor

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
Copy link
Member

bapt commented Nov 10, 2022

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
Copy link
Contributor

michael-o commented Nov 10, 2022

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
Copy link
Member

bapt commented Nov 10, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants