Skip to content
Snippets Groups Projects
Select Git revision
  • deposit
  • master default protected
  • mr/document-debian-upgrade-per-data-silos
  • make-reference-name-unique
  • generated-differential-D8969-source
  • generated-differential-D8894-source
  • generated-differential-D8870-source
  • generated-differential-D8314-source
  • gitlab-contrib
  • feature/add-swh-fuse
  • feature/myst
  • v0.0.0
12 results
Blame Permalink
nixguix.rst 2.54 KiB

Nix and Guix

This page documents how |swh| archives source packages from the GNU Guix and Nix distributions.

Those distributions provide functional package managers, respectively GNU Guix and Nix with similar properties (e.g. transactional, declarative up to the operating system, reproducible, ...). Definition of packages is dependent on their respective DSL. As it was not parsable easily nor listing api existed, community effort was done upstream to provide regular extraction of an origin listing (as json manifest).

|swh|'s NixGuix lister queries respectively those remote origins listing. They contain various types of origins.

As a result |swh| has a lister and various loaders to deal with those origins. Those origins can be: - simple file (visit type 'content') - tarballs (visit type 'tarball-directory') - 'svn' repository (full or at a specific revision, visit type 'svn-export') - 'git' repository (full or at a specific commit, visit type 'git-checkout') - 'hg' repository (full or at a specific hg changeset, visit type 'hg-checkout').

Origin URLs match each main url provided in the manifest.

For some cases, there can be mirror urls which are used as fallback artifact retrieval when the main url is no longer available.

No extrinsic nor intrinsic metadata is happening on the lister's side.

But for some kind of origins, 'content', 'tarball-directory', 'svn-export', 'hg-checkout', 'git-checkout', extra information regarding the checksums used ('standard', e.g. sha256, or 'nar', specific intrinsic identifier used by Guix and Nix), are transmitted to their respective loaders. During their respective ingestion, those checksums are verified. If the checksum does not match, the artifact is rejected and the visit is failed. If not, the artifact is ingested. Note that a new entry is recorded in the ExtID table to map the SWHID of the content or directory ingested to their their original checksum.

TODO:

  • summary of the lister's algorithm
  • summary of the loader's algorithm
  • index extrinsic metadata?
  • index intrinsic metadata?

Resources: