mirror of
https://github.com/foo-dogsquared/wiki.git
synced 2025-01-31 07:57:57 +00:00
aea7015cd5
Apparently, the convention (at least starting from 2018) is to make the keywords and block names to be in lowercase as stated from one of the following discussions at https://orgmode.org/list/87tuuw3n15.fsf@nicolasgoaziou.fr/. The files was updated with a one liner of shell. However, this is Emacs and org-mode does have an API to let you do stuff in your config and interact with the documents internally so it is not an elegant solution in any way.
35 lines
2.7 KiB
Org Mode
35 lines
2.7 KiB
Org Mode
#+title: Functional package management
|
|
#+author: "Gabriel Arazas"
|
|
#+email: "foo.dogsquared@gmail.com"
|
|
#+date: "2020-09-19 08:31:48 +08:00"
|
|
#+date_modified: "2020-09-09 05:26:32 +08:00"
|
|
#+language: en
|
|
#+options: toc:t
|
|
#+property: header-args :exports both
|
|
|
|
|
|
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 [[file:2020-09-04-19-57-06.org][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 [[file:2020-04-12-11-20-53.org][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).
|