:properties:
:id:       30d6a3d2-42f3-4f49-8d4c-bf433dc82350
:roam_refs: @packagingconPackagingGrailLudovic2021
:end:
#+title: The Packaging Grail - Ludovic Courtès | PackagingCon 2021
#+date: 2021-12-28 21:27:18 +08:00
#+date_modified: 2021-12-28 22:51:08 +08:00>
#+published: 2021-11-23
#+author: Ludovic Courtès
#+source: https://youtu.be/tcTOkXlE_ac
#+language: en

* Synopsis
- a primer to [[id:be917383-84c4-4bf5-9ca0-b04bfb778f4f][Guix package manager]] and its goals
  - it is free as in [[id:e8c1218f-35a4-4dd3-a174-5d8f848b74b2][Free software]]
  - a universal package manager that tries to cover all dependencies from different programming languages similar to [[id:3b3fdcbf-eb40-4c89-81f3-9d937a0be53c][Nix package manager]]
  - transparent through the [[id:fe9e21bc-3b38-4d0f-a785-253248a38ed7][Reproducible builds]] initiative integrating it into the package manager (e.g., =guix challenge=)
- focus on isolated builds leading to bit-identical builds and [[roam:Bootstrappable builds]] (building everything from source) enforcing further transparency and more security (e.g., "Trusting trust" attacks, creating backdoors through compiler bugs)
- making efforts to reduce the binary blobs required to boot an operating system from scratch through GNU Mes
- the balance to the right way versus pragmatism;
  other solutions may present to be faster and more convenient versus doing things the "right way" (e.g., comparing Pytorch package from Guix built from source versus Pypi containing prebuilt binaries; see [[Potential problems]]);
  in this case, Guix is drawing the line by providing tools to make packaging easier (e.g., =guix import=)

* Potential problems
- binary packages in package repositories (e.g., =torch= package in Pypi) [fn:: There's also =PyQt-Qt6= package from Pypi.]
  - developer-uploaded binaries which may contain other modifications and harder to verify
  - no indication of sources from random binaries
  - licenses issues may pop up
- no standard way to reproduce builds and verify so anyone can upload anything;
  this can create supply chain issues
  - see the left-pad issue from npm that happened years ago
- with project-specific and language-specific package managers (e.g., npm, cargo, pip), a lot of the overall reach of the software can feel isolated;
  Guix is intending to at least provide a way to unify them (as it is one of the goals, after all)
- mostly related to software testing — e.g., missing test dependencies,
- hosted source can be different from upstream;
  [fn:: I personally think the binaries from Visual Studio Code is another example.]

* Presenter's wish
- *move non-free software*;
  at the very least, move it to another repository to let people make informed decisions;
  not only this cannot be reproduced well but also impedes security
- *disallow developer-uploaded binaries*;
  the talk presented an example with the previous case with Debian allowing it some time ago;
  if it is allowed, at least provide a way to reproduce it;
- *accurate licensing info*
- *accurate package data from repositories* (e.g., dependencies, license)
- *good description/synopsis*