mirror of
https://github.com/foo-dogsquared/wiki.git
synced 2025-01-31 04:58:21 +00:00
34 lines
2.7 KiB
Org Mode
34 lines
2.7 KiB
Org Mode
: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).
|