|
1 | 1 | # OSS Reproducible |
2 | 2 |
|
3 | | -The purpose of *oss-reproducible* is to analyze open source packages for reproducibility. We start with |
| 3 | +The purpose of *oss-reproducible* is to analyze open source packages for `semantic reproducibility`. We start with |
4 | 4 | an existing package (for example, the NPM "left-pad" package, version 1.3.0), and we try to answer the |
5 | | -question, **Do the package contents authentically reflect the purported source code?** |
| 5 | +question, **How accurately does the source code represent the published package?** |
6 | 6 |
|
7 | 7 | ## Why Reproducibility? |
| 8 | +Reproducible builds allow confidence that packages are derived from the source code that produced them. |
| 9 | + |
| 10 | +## Semantic Reproducibility |
| 11 | +A project build is `semantically reproducible` if its build results can be either recreated exactly (a bit for bit [reproducible build](https://en.wikipedia.org/wiki/Reproducible_builds)), or if the differences between the release package and a rebuilt package are not expected to produce functional differences in normal cases. |
| 12 | + |
| 13 | +For example, the rebuilt package might have different date/time stamps, or one might include files like .gitignore that are not in the other and would not change the execution of a program under normal circumstances. |
8 | 14 |
|
9 | 15 | ## How It Works |
10 | 16 |
|
11 | 17 | We start by downloading the package from the respective package repository, using OSS Download. Then |
12 | 18 | we look for the source (using OSS Find Source) and try to find and download the correct version of it. |
13 | 19 |
|
14 | | -OSS Reproducible uses "strategies" to try to correlate source code with the package contents. These |
| 20 | +OSS Reproducible uses `strategies` to try to correlate source code with the package contents. These |
15 | 21 | strategies include: |
16 | 22 |
|
17 | | -* PackageMatchesSourceStrategy: Do the package contents exactly match the source code repository |
| 23 | +* `PackageMatchesSourceStrategy`: Do the package contents exactly match the source code repository |
18 | 24 | contents? |
19 | | -* PackageContainedInSourceStragegy: Does every file in the package exist in the source code repository? |
| 25 | +* `PackageContainedInSourceStragegy`: Does every file in the package exist in the source code repository? |
20 | 26 | Note that this is different from the previous strategy; for example, unit tests in the source repository |
21 | 27 | that don't appear in the package would be fine for this strategy. |
22 | | -* AutoBuildProducesSamePackage: Can we re-build the package from the source code repository? Since |
| 28 | +* `AutoBuildProducesSamePackage`: Can we re-build the package from the source code repository? Since |
23 | 29 | there is a huge variety in build methods, this can very difficult, or in many cases, impossible. |
24 | | -* OryxBuildStrategy: The Microsoft Oryx project has independent logic to attempt to "build" source |
| 30 | +* `OryxBuildStrategy`: The Microsoft Oryx project has independent logic to attempt to "build" source |
25 | 31 | code repositories, so we leverage that as well. |
26 | 32 |
|
| 33 | +OSS Reproducible calculates an estimate of the similarity between the published package from OSS-Download |
| 34 | +and the associated source code from OSS-Find-Source. |
| 35 | + |
27 | 36 | ## Ignoring Files |
28 | 37 |
|
29 | | -Certain files are uninteresting from a reproducibility perspective, and are excluded from analyses. |
| 38 | +Certain files are uninteresting from a `semantic reproducibility` perspective and are excluded from analyses. |
30 | 39 | These files are defined in Strategies/PackageIgnoreList.txt. |
31 | 40 |
|
32 | 41 | ## Contributing to OSS Reproducible |
|
0 commit comments