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

Latest commit

 

History

History
67 lines (45 loc) · 3.94 KB

2022-10-12.md

File metadata and controls

67 lines (45 loc) · 3.94 KB

Nixpkgs Architecture Team Meeting #13

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

Design wiki

@roberth Start of a design wiki for nixpkgs, where we can organize the knowledge from the meetings. Discussion points from here:

  • Extend the scope of the team to maintain a knowledge base about the potential design of Nixpkgs in a wiki

  • Delineate what should go into the wiki as opposed to what should be in separate discussions and in official docs

  • @infinisil went over the rest of that thread so far

    • @Ericson2314: Re to valentin's comment's: Anything that's done would also be documented in the usual places, so not a problem. But also a bit skeptical of the benefit
    • @infinisil mentions it is a place to refer people when the same tangent show up again and again.
    • @Ericson2314: That makes a lot of sense! Like a fandom "lore wiki" in a way

Hard decisions for meetings

@mkaito Only rely on meetings for hard decisions where the entire team needs to be there (on Matrix)

  • @infinisil: Good to see everyone, build report, etc. So benefits of meetings beyond decision making or non-personal information exchange.
  • @roberth: Sees both sides, meetings have been unproductive in the past, for now wants to keep every week.
  • @Ericson2314: Agrees with @infinisil, have had some messy meetings, but the community needs more venues, might get rambling because we new to this and have a "backlog" of things to talk about, but the more things we do together, the more structure evolves, improving workings over time

More functionality in packages passthru

@abathur Provide more config/util(/maintenance?) functionality by functions in a package’s passthru (on Discourse)

  • @growpotkin: For complex modules, which we could use for packages instead, it's sometimes useful yes. But top-level functions are also sometimes the right thing.

  • @growpotkin was loking at POP a bit

  • YANTS yet another Nix typechekcing, a TVL project

Providing runtime deps impurely after building

  • @growpotkin: had used patchelf for providing runtime deps after the fact

    • @Ericson2314: symbol files

  • @infinisil: coversation might have been about something else:

    • try to avoid runtime-only dep being compiled-in somehow
    • change openSSL version or similar

  • @growpotkin: to even run the test suite for libtool he had to do some of that

  • @infinisil: https://gist.github.com/infinisil/3366e7dfc9a01f6eeb25b5cb475cc585

  • @Ericson2314: Think we can do this more purely

    • old goal: security rebuildings are not mass rebuilds
    • old idea: NixOS/nix#1080, but don't think we need that anymore
    • Instead of building against .so's, build against symbol files instead (see also TAPI file)
    • Only at link time decide on explicit libraries to link against
    • Use symbol files with headers
    • CA derivations helps a lot
      • @growpotkin agrees, much easier for "complexity" and "crowd control"

  • @growpotkin: there are some quirks, C++ especially