wiki/notebook/2020-09-19-08-31-48.org
Gabriel Arazas 732ef34ca8 Update notebook as of 2021-10-09
Welp, I rarely take notes nowadays due to more specialized work and
stuff. Though, I should have more incentives for writing. In other
words, I'm just lazy. ;p

More free-thinking morning sessions should be done soon.
2021-10-09 18:14:46 +08:00

2.8 KiB

Functional package management

Functional package management (FPM) is the next step forward pioneered by Eelco Dolstra with Nix package manager as the living implementation. 1[GNU Guix]] and Fedora Silverblue.]

It was first realized from the thesis "The Purely Functional Software Deployment Model".

The conceptual overview of it is similar to 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 reproducible builds (thus gaining a reach for 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.
  • As a consequence of the statefulness, traceability is almost non-existent.
  • 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.

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).

1

Eventually, it became the inspiration for other projects that focuses on reproducibility and security such as [[https://guix.gnu.org/