:PROPERTIES: :ID: bfed6daf-4c2b-4426-bab9-2804caa5e079 :END: #+title: Functional package management #+date: "2020-09-19 08:31:48 +08:00" #+date_modified: "2021-05-04 20:52:16 +08:00" #+language: en Functional package management (FPM) is the next step forward [[https://edolstra.github.io/pubs/nixos-icfp2008-final.pdf][pioneered by Eelco Dolstra]] with [[https://nixos.org/][NixOS]] as the living implementation. [fn:: Eventually, it became the inspiration for other projects that focuses on reproducibility and security such as [[https://guix.gnu.org/][GNU Guix]] and [[https://silverblue.fedoraproject.org/][Fedora Silverblue]].] The conceptual overview of it is similar to [[id:7e1e2bcc-6f70-4624-a049-b42f9db5e28b][Functional programming]] with how it views with data and functions (in this case, packages and build processes). It views that packages are a unique result from combining different things: dependencies, build processes, versions, and more. If a dependency has updated its patch version or a build instruction has revised with one line of change, it will result in a "new" package as the output even if the package isn't any different. Coming from a functional approach, it also features statelessness and immutability, making it a reliable toolkit for [[https://reproducible-builds.org/][reproducible builds]] (thus gaining a reach for [[id:6eeb7a24-b662-46d6-9ece-00a5028ff4d8][Reproducible research]]). The problems that FPM attempts to solve come from the critique of the traditional package management which is still dominant as of today (2020-08-31). Here are some of the problems on a traditional Linux-based system: - The statefulness of the entire system leads to similar situations on Windows' dependency hell problem. - Multiple versions of packages are hard to place side-by-side which is used by developers targetting stable versions while experimenting with the latest versions. - Destructive ongoing updates which consists of replacing the current version with the updated version while the update is going. - Traceability is almost non-existent with all of the statefulness of the system. The functional approach with the unique output and immutable variables addresses the listed problems in some way. - A package is built from an input resulting in a package on a unique immutable location, eliminating the statefulness in the process. - Since each revision results in a new location, the same package with different versions can be easily placed side-by-side. - With the way how packages built, the old system can be kept giving the possibility for the user to rollback to those previous versions. - The functional approach creates a guaranteed output, making it predictable (and traceable).