|
1 |
| -#import "imports/preamble.typ": * |
| 1 | + #import "imports/preamble.typ": * |
2 | 2 | #import "theme/template.typ": *
|
3 | 3 | #import "theme/common/titlepage.typ": *
|
4 | 4 | #import "theme/common/metadata.typ": *
|
@@ -366,22 +366,32 @@ reproducibility becomes increasingly challenging, as software packages may
|
366 | 366 | become obsolete or unavailable over time.
|
367 | 367 |
|
368 | 368 | To circumvent this limitation, researchers and developers can adopt proactive
|
369 |
| -measures to ensure the reproducibility of their software builds. One approach is |
370 |
| -to archive the source code and dependencies of the software package, preserving |
371 |
| -them in a secure and accessible repository. This is what projects like Software |
372 |
| -Heritage #cite(<swh>, form: "normal") is trying to achieve. By archiving the |
373 |
| -source code and dependencies, researchers and developers can safeguard against |
374 |
| -the loss of critical software components and maintain the reproducibility of |
375 |
| -their builds over time. Additionally, implementing a caching layer to store |
376 |
| -build outputs can significantly enhance reproducibility. This allows users to |
377 |
| -retrieve precompiled build outputs, thereby avoiding the need to compile the |
378 |
| -source code on their machines if the corresponding cached build exists. |
379 |
| -Nix facilitates the creation of such cached build layers due to its principles |
380 |
| -(@def-functional-package-management), as it produces immutable directories based |
381 |
| -on sources. This means that modifying existing cached builds is not possible, |
382 |
| -mitigating potential security issues related to accidental modifications. It's |
383 |
| -worth noting that this level of immutability and reproducibility is not the case |
384 |
| -with all package managers. |
| 369 | +measures to ensure the long-term reproducibility of their software builds. One |
| 370 | +approach is to archive the source code and dependencies of the software package, |
| 371 | +preserving them in a secure and accessible repository. This is what projects |
| 372 | +like Software Heritage #cite(<swh>, form: "normal") is trying to achieve. By |
| 373 | +archiving the source code and dependencies, researchers and developers can |
| 374 | +safeguard against the loss of critical software components and maintain the |
| 375 | +long-term reproducibility of their builds over time. Since November 2018, Guix |
| 376 | +has incorporated support for Software Heritage, "making it the first free |
| 377 | +software distribution backed by a stable archive" |
| 378 | +#cite(<swguix2018>, form:"normal"). This integration allows Guix to fall back to |
| 379 | +the Software Heritage archive if it fails to download source code from its |
| 380 | +original location. As a result, package definitions in Guix do not need to be |
| 381 | +modified; they still refer to the original source code URL, but the downloading |
| 382 | +machinery will transparently access Software Heritage when necessary. This |
| 383 | +feature significantly enhances the robustness of software builds in Guix by |
| 384 | +ensuring that source code remains accessible even if the original URLs become |
| 385 | +unavailable. Alternatively, implementing a caching layer to store build outputs |
| 386 | +can significantly enhance reproducibility. This allows users to retrieve |
| 387 | +precompiled build outputs, thereby avoiding the need to compile the source code |
| 388 | +on their machines if the corresponding cached build exists. Nix extensively uses |
| 389 | +that feature and facilitates the creation of such cached build layers due to its |
| 390 | +principles (@def-functional-package-management), as it produces immutable |
| 391 | +directories based on sources. This means that modifying existing cached builds |
| 392 | +is not possible, mitigating potential security issues related to accidental |
| 393 | +modifications. It's worth noting that this level of immutability and |
| 394 | +reproducibility is not the case with all package managers. |
385 | 395 |
|
386 | 396 | ==== Standardisation
|
387 | 397 |
|
|
0 commit comments