foodogsquared/wiki
1
0
Fork 0
mirror of https://github.com/foo-dogsquared/wiki.git synced 2025-01-31 04:58:21 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity
7139ee4f17
wiki/2020-09-19-08-31-48.org
Gabriel Arazas c0923b5253 Migrate notes to org-roam v2
2021-05-05 00:07:40 +08:00

2.7 KiB
Raw Blame History

Functional package management

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

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

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