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

Describe limitations #15

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from
Draft

Describe limitations #15

wants to merge 1 commit into from

Conversation

michael-o
Copy link
Member

This closes #15

@michael-o michael-o requested a review from hboutemy February 3, 2023 23:15
Copy link
Member

@hboutemy hboutemy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

definitely no: that sentence is not true said like that, goes a wrong route about what Reproducible Builds is and what a rebuild comparison success or failure means

if you really want to say something in that direction, we can eventually say that

Having artifact:compare fail on your build does not always mean that the build is not reproducible: it may be that the environment of the current build has too much differences with the environment from the reference build (for example not same JDK release, not same Maven version, not same timezone, ...). Updating the environment may be sufficient to get the same build output as the reference build; then have achieved to reproduce the reference build.

On the other side, having a successful rebuild locally does not explicitely define what the environment prerequisites are, nor how strictly they are described: someone with another environment may discover later that an environment parameter was involved in rebuild comparison success that was implicitely set (like timezone, or Maven release used).

And defining what is acceptable as an environment prerequisite for judging that the build is sufficiently "easily" reproducible is out of the scope for the plugin: is it acceptable to require a timezone, or a user language, or a Maven version? This is more best-practices to ease rebuilders' life.

For example: efforts have been put in maven-jar-plugin to not store precise Maven release (major.minor.patch) or JDK release (major.minor.release_patch or JDK vendor) in output file, because it has been judged that it was adding too much constraints on the rebuild environment definition, without much value (experience shows that output result is stable).
In general, other plugins have tried to avoid depending on the timezone or user language. But nothing is absolute: one may require for a precise environment setup.

All these explanations are my experience from rebuilding releases done by others and publishing results on Maven Central https://github.com/jvm-repo-rebuild/reproducible-central
They are true, but I fear they are complex to grasp...

@michael-o
Copy link
Member Author

Right, I will try to rephrase tomorrow.

@michael-o michael-o marked this pull request as draft February 4, 2023 00:40
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

Successfully merging this pull request may close these issues.

2 participants