Skip to content
This repository has been archived by the owner on Mar 11, 2024. It is now read-only.

Latest commit

 

History

History
53 lines (39 loc) · 2.98 KB

2022-10-19.md

File metadata and controls

53 lines (39 loc) · 2.98 KB

Nixpkgs Architecture Team Meeting #14

The following sections describe the agenda of the meeting and also serve as a place to put the corresponding meeting notes. After the meeting, these notes are moved to https://github.com/nixpkgs-architecture/meetings. This HedgeDoc link will be reused for all subsequent meetings.

Protocol

Notes

Spack: External dependencies and specifications

Notes:

  • @tgamblin: Still a SAT solver
  • @tgamblin: Another idea is Z3, SMT
    • Seems harder to specify
  • @tgamblin: externals aren't as pure as you'd like
    • Specifying dependencies, build options etc.
    • Could get incompatible upgrade
  • @tgamblin: Main thing about the paper is reusing built binaries
    • If you have a minor tweak, tries to reuse already existing binaries
    • Spack knows about which binaries are available cached
    • Another purity thing we're planning to do: Currently can't build on one version, deploy for another. Things like ABI compatibility.
    • Stub symbols sounds similar to something we've done. There's abstract and concrete specs, only give requirements during abstract specs, certain flags. Should only deploy with libraries that fulfil the spec
    • Don't recommend writing own solver
  • @nbp: Alternative to SAT solver: Nixpkgs doesn't need one as we're baking one solution. Same for updating dependencies, security updates PR NixOS/nixpkgs#10851
    • @nbp: Not that complicated, but hard to integrate into nixpkgs
    • SOS (NixOS/rfcs#3) would make makes this a lot simpler
    • @tgamblin: Resolver is there because packages typically aren't written with specific versions, but rather with bounds. Those are preserved and are given to the solver. Can work with existing binaries and external packages. ABI compatibity with the shipping security updates PR
    • @nbp: Up to submitter to ensure compatibility. Generally not our problem.
    • @nbp: Always building latest package. With CV change applied to another, building one latest version for base, one with it applied
    • @tgamblin: Currently struggling with ABI incompatibilities.
    • @infinisil: Nixpkgs can always use the latest version, authorative, single CI. With flakes people want more distributed Nix expressions and dependencies, version requirements come up more.
    • @tgamblin: Environments remind me a bit of flakes

Deep runtime dependency substitution

The Nixpkgs Architecture Team is on nixos.org now

Problems with RFC 127

JSON schema for NixOS options