Token导航 LogoToken导航

Agent Skill · 研究检索

packaging-binary-for-nix(为 nix 打包二进制文件)

packaging-binary-for-nix 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

packaging-binary-for-nix 是研究检索类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为需要联网;许可证为 MIT,暂无第三方扫描结果,按安装量在研究检索类的 73,675 个 Skill 里排第 73,249。

总安装 99周安装 4GitHub Stars 公开资料未说明下载 31核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
MIT

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:packaging-binary-for-nix(为 nix 打包二进制文件)
来源仓库:https://github.com/lihaoze123/my-skills
仓库路径:skills/packaging-binary-for-nix
安装命令:
npx skills add lihaoze123/my-skills --skill "packaging-binary-for-nix"
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

AgentSkills.tonpx skills
npx skills add lihaoze123/my-skills --skill "packaging-binary-for-nix"

这个 Skill 是做什么的

研究检索类 Skill 主要解决「找资料、核对事实、把来源整理清楚」的问题,通常会让助手先检索再总结。

用于查找并安装 AI 代理的技能,支持关键词检索与结果筛选。适合在 Codex、Claude、Cursor、Gemini CLI 中快速定位候选技能。通过 npx skills add 命令从 GitHub 仓库安装指定技能。安装前需确认权限范围、维护状态及是否触发联网或文件读写。

建议结合原始 README 验证功能边界与使用限制。

来源仓库内路径:skills/packaging-binary-for-nix

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add lihaoze123/my-skills --skill "packaging-binary-for-nix";命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它需要需要联网,先在测试目录或测试账号里跑,确认没问题再放到正式项目。

常见问题

6 条

packaging-binary-for-nix 怎么安装?

在终端执行 npx skills add lihaoze123/my-skills --skill "packaging-binary-for-nix"。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

packaging-binary-for-nix 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

packaging-binary-for-nix 需要什么权限?

权限级别是需要联网。该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

packaging-binary-for-nix 是免费的吗?

来源标注的许可证是 MIT。本站不代收任何费用,也不托管安装包;能否商用、要不要署名,以许可证原文为准。

packaging-binary-for-nix 用的人多吗?

公开数据是累计安装 99 次,近一周安装 4 次,下载 31 次。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

packaging-binary-for-nix 安全吗?

没有查到第三方扫描结果,安全性无法从公开资料判断,安装前请自行审查源码、依赖和命令行为。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 许可证明确为 MIT,商用和分发边界好判断。

先想清楚的地方

  • 没有第三方扫描结果,安全性只能靠自己读源码判断。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理研究检索类任务、又不想每次都手写提示词的人。

不太适合

  • 要求有安全扫描结论才肯安装的团队。
  • 需要厂商级技术支持和 SLA 的生产系统。

研究检索类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
find-skills

寻找技能 · Codex、Claude

31,199,81316,486操作浏览器MIT有提醒
self-improving-agent

自我改进 Agent · OpenClaw

16,464,0023,396接触敏感数据MIT-0通过
soultrace

灵魂追踪 · Codex、Claude

7,588,94412需要联网未明确有提醒
self-improving

自我完善 · OpenClaw

6,829,2841,046需要联网MIT-0通过
microsoft-foundry

微软代工厂 · Codex、Claude

6,614,144764调用外部服务未明确有提醒
packaging-binary-for-nix

为 nix 打包二进制文件 · 本页

99—需要联网MIT未收录

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

Packaging Binary Distributions for Nix

Overview

Extract and patch binary packages within Nix builds for reproducibility. Core principle: Source from original archive directly, never from pre-extracted directories.

When to Use

Use when:

  • Converting binary packages (.deb,.rpm,.tar.gz,.zip) to Nix derivations
  • Packaging proprietary/closed-source software distributed as binaries
  • Electron/GUI apps show "library not found" errors
  • User provides pre-extracted binary contents
  • Binary distributions need library path fixes

Don't use for:

  • Software available in nixpkgs
  • Source-based packages (use standard derivation)
  • AppImages (use appimage-run or extract and patch)

Essential Pattern

For.deb packages:

{ pkgs }:

pkgs.stdenv.mkDerivation rec {
  pname = "appname";
  version = "1.0.0";

  # ✅ Source the archive directly
  src = ./AppName-${version}-linux-amd64.deb;

  # ✅ autoPatchelfHook fixes library paths automatically
  nativeBuildInputs = with pkgs; [
    autoPatchelfHook
    dpkg  # for .deb extraction
  ];

  # ✅ Runtime library dependencies
  buildInputs = with pkgs; [
    stdenv.cc.cc.lib
    glib
    gtk3
    # Add libraries based on ldd output
  ];

  # ✅ Extract during build (.deb format)
  unpackPhase = ''
    ar x $src
    tar xf data.tar.xz
  '';

  # For .tar.gz/.tar.bz2: stdenv auto-detects
  # For .zip: nativeBuildInputs = [ unzip ];
  # For .rpm: nativeBuildInputs = [ rpm, cpio ];

  installPhase = ''
    mkdir -p $out
    cp -r opt/AppName/* $out/

    # Fix desktop file paths if exists
    if [ -f usr/share/applications/app.desktop ]; then
      mkdir -p $out/share/applications
      cp usr/share/applications/app.desktop $out/share/applications/
      substituteInPlace $out/share/applications/app.desktop \
        --replace-fail "/opt/AppName" "$out"
    fi
  '';
}

Archive Format Examples

RPM packages:

nativeBuildInputs = [ autoPatchelfHook rpm cpio ];

unpackPhase = ''
  rpm2cpio $src | cpio -idmv
'';

Tar.gz/tar.bz2/tar.xz:

# stdenv auto-detects these formats
src = ./app-${version}.tar.gz;
# unpackPhase not needed

ZIP archives:

nativeBuildInputs = [ autoPatchelfHook unzip ];

unpackPhase = ''
  unzip $src
'';

Plain directory (already extracted):

# ❌ Don't do this - not reproducible
src = ./extracted-app;

# ✅ Instead: create tarball first
# tar czf app.tar.gz extracted-app/
# Then: src = ./app.tar.gz;

Quick Reference

TaskSolution
Local archivesrc =./package-${version}.tar.gz (relative path)
Remote archivesrc = fetchurl {url = "..."; hash = "sha256-...";}
Extract.debar x $src && tar xf data.tar.xz in unpackPhase + dpkg
Extract.rpm`rpm2cpio $src \cpio -idmv` in unpackPhase + rpm, cpio
Extract.tar.gzAuto-detected by stdenv
Extract.zipAdd unzip to nativeBuildInputs
Fix librariesAdd autoPatchelfHook to nativeBuildInputs
Find missing libsRun binary, check errors, add to buildInputs
Wrapper scriptsUse makeWrapper in nativeBuildInputs
Version syncUse ${version} in filename: src =./app-${version}.tar.gz

Dependencies: The Three Categories

digraph dependencies {
    "What is this?" [shape=diamond];
    "When needed?" [shape=diamond];
    "nativeBuildInputs" [shape=box];
    "buildInputs" [shape=box];
    "propagatedBuildInputs" [shape=box];

    "What is this?" -> "When needed?";
    "When needed?" -> "nativeBuildInputs" [label="build-time tool"];
    "When needed?" -> "buildInputs" [label="runtime library"];
    "When needed?" -> "propagatedBuildInputs" [label="users need it"];

    "nativeBuildInputs" -> "dpkg\nautoPatchelfHook\nmakeWrapper" [style=dashed];
    "buildInputs" -> "gtk3\nglib\nlibpulseaudio" [style=dashed];
}

nativeBuildInputs: Tools for building (dpkg, autoPatchelfHook, makeWrapper) buildInputs: Libraries the app links against (gtk3, glib, mesa) propagatedBuildInputs: Rarely needed for.deb packaging

Source File Options

For local archives (development/testing):

src = ./app-${version}.tar.gz;  # Relative path in same directory
src = ./app-${version}.deb;     # Works for any archive format

For distributed packages:

src = fetchurl {
  url = "https://example.com/releases/app-${version}.tar.gz";
  hash = "sha256-AAAA...";  # Get with: nix-hash --type sha256 --flat archive
};

Never use absolute paths - they break on other machines.

Common Mistakes

MistakeWhy It FailsFix
src =./extracted/Not reproducible, breaks on other machinessrc =./app.tar.gz
src = /home/user/app.tar.gzAbsolute path breaks portabilitysrc =./app.tar.gz (relative)
src = /home/user/app.tar.gz in fetchurlStill an absolute local pathUse ./app.tar.gz or real URL
Missing autoPatchelfHookBinary can't find librariesAdd to nativeBuildInputs
Libraries in nativeBuildInputsWrong category - they're runtime depsMove to buildInputs
Hardcoded version in filenameMust update 2 places when upgradingUse src =./app-${version}.tar.gz
Wrong extractor for format.zip fails,.rpm fails with tarCheck Quick Reference for format

Red Flags - STOP

If you catch yourself thinking:

  • "User already extracted it, use that directory" → NO, source from original archive
  • "Absolute path works for me locally" → Breaks for others, use relative
  • "Just add more libraries until it works" → Find actual dependencies with ldd
  • "Quick local test, absolute path is fine" → Bad habits stick, do it right
  • "Mixed extraction (some pre-extracted)" → Extract everything in unpackPhase

All of these mean: Use original archive as source, extract in build.

Finding Missing Libraries

# After building
result/bin/appname  # Run and check errors

# Or check with ldd
ldd result/opt/AppName/appname

# Look for "not found" libraries
# Add corresponding Nix packages to buildInputs

Common library mappings:

  • libgtk-3.so.0 → gtk3
  • libglib-2.0.so.0 → glib
  • libpulse.so.0 → libpulseaudio
  • libGL.so.1 → mesa or libglvnd
  • libxkbcommon.so.0 → libxkbcommon (NOT xorg.libxkbcommon)

Version Management

# ✅ Good: version variable used in filename
pkgs.stdenv.mkDerivation rec {
  pname = "myapp";
  version = "1.2.3";
  src = ./myapp-${version}-linux-x86_64.tar.gz;
}

# ❌ Bad: version hardcoded separately
pkgs.stdenv.mkDerivation rec {
  pname = "myapp";
  version = "1.2.3";
  src = ./myapp-1.2.2-linux-x86_64.tar.gz;  # Mismatch!
}

Electron Apps: Extra Considerations

Electron apps often need:

buildInputs = with pkgs; [
  # Base
  stdenv.cc.cc.lib
  # GTK/GUI
  glib gtk3 cairo pango gdk-pixbuf
  # X11
  xorg.libX11 xorg.libXcomposite xorg.libXdamage
  xorg.libXext xorg.libXfixes xorg.libXrandr
  # System
  dbus nspr nss cups libdrm mesa
  alsa-lib libpulseaudio
];

Add GPU flags in wrapper:

makeWrapper $out/opt/App/app $out/bin/app \
  --prefix LD_LIBRARY_PATH : "${pkgs.lib.makeLibraryPath buildInputs}" \
  --add-flags "--disable-gpu-sandbox"

Advanced: Binaries That Resist Patching

Some proprietary software detects modifications and refuses to run (e.g., license checks, integrity validation). For these cases, autoPatchelfHook won't work.

Solution: FHS environment with Bubblewrap

Create a standard Linux filesystem hierarchy in a container:

{ buildFHSEnv }:

buildFHSEnv {
  name = "myapp";
  targetPkgs = pkgs: with pkgs; [
    # All runtime dependencies
    glib gtk3 openssl
  ];

  runScript = "${extracted}/bin/myapp";
}

Or use steam-run for quick testing (includes many common libraries):

steam-run ./myapp

When to use:

  • Binary detects modifications (license/DRM checks)
  • autoPatchelfHook breaks functionality
  • Quick prototyping before proper packaging

Trade-off: Larger closure size, less reproducible than autoPatchelfHook.

Build Phases and Hooks

The standard environment runs 7 phases. You can customize any phase:

stdenv.mkDerivation {
  # ...

  # Before unpacking
  preUnpack = ''
    echo "About to extract..."
  '';

  # After patching, before configure
  postPatch = ''
    # Fix hardcoded paths
    substituteInPlace Makefile \
      --replace "/usr/bin" "$out/bin"
  '';

  # After installation
  postInstall = ''
    # Wrap binary with runtime dependencies
    wrapProgram $out/bin/myapp \
      --prefix PATH : ${lib.makeBinPath [ ffmpeg ]} \
      --set MY_VAR "value"
  '';
}

Phase order: unpack → patch → configure → build → check → install → fixup

Common hooks:

  • preInstall / postInstall - Modify installation
  • postPatch - Fix source before building
  • postFixup - Final touches after automatic fixup

Wrapper Programs: wrapProgram

When binaries need specific environment variables or PATH entries:

nativeBuildInputs = [ makeWrapper ];

postInstall = ''
  wrapProgram $out/bin/myapp \
    --prefix PATH : "${lib.makeBinPath [ ffmpeg imagemagick ]}" \
    --prefix LD_LIBRARY_PATH : "${lib.makeLibraryPath [ vulkan-loader ]}" \
    --set QT_QPA_PLATFORM "xcb" \
    --add-flags "--disable-telemetry"
'';

Common use cases:

  • Add tools to PATH (ffmpeg, imagemagick)
  • Set environment variables (QT_*, GTK_*)
  • Add default flags
  • Extend LD_LIBRARY_PATH for dynamic loading

Real-World Impact

Without this pattern:

  • Package works on your machine only
  • Breaks when shared or used in flakes
  • Manual extraction required before every build
  • Version mismatches go unnoticed
  • Format-specific extraction errors

With this pattern:

  • Fully reproducible across machines
  • Works in flakes, NixOS configs, nix-env
  • Automatic extraction on every build
  • Version changes = single line edit
  • Handles.deb,.rpm,.tar.gz,.zip consistently

平台分布

Claude Code

74.86%
按下载量换算23

安全审计

暂无安全审计结果可展示。

权限和风险

需要联网

该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。目前只有一个公开来源,建议同时核对源仓库。

继续浏览同类 Skills