Guix로 바이너리 패키징하기: NixOS와의 차이점은?

Guix의 `copy-build-system`을 사용하여 정적 링크된 바이너리를 패키징하는 방법을 설명함

동적 라이브러리 의존성 처리의 복잡성과 rpath 업데이트 필요성을 논의함

Guix의 빌드 시스템이 NixOS보다 이해하기 쉽고 유용하다는 평가가 있음

NixOS는 철학적으로 외부 바이너리 직접 실행을 지양하나, Guix는 상대적으로 유연한 접근 방식을 보임

Guix의 `copy-build-system`과 정적 바이너리

본문에서는 Guix의 `copy-build-system`을 활용하여 정적 링크된 바이너리를 패키징하는 과정을 상세히 설명합니다. `install-plan` 인자를 통해 `/bin` 디렉토리로 복사하는 간단한 방식이 제시되었으나, 이는 의존성이 없는 경우에 한정됩니다. 해당 바이너리는 `/gnu/store`에 설치되며, 사용을 위해서는 사용자 패키지나 시스템 패키지로 추가해야 함을 명시합니다.

동적 라이브러리 의존성 처리의 복잡성

댓글에서는 동적 라이브러리 의존성이 있는 경우 패키징이 훨씬 복잡해진다고 지적합니다. Nonguix의 바이너리 빌드 시스템이나 NixOS의 `rpath` 업데이트, `patchelf`, `autoPatchelfHook`과 같은 도구를 사용하여 라이브러리 경로를 수정해야 함을 강조합니다. 특히 `caddy`의 경우 자체 포함(self-contained)되어 있어 `copy-build-system`으로 해결 가능했지만, 일반적인 경우는 아니라는 점이 부각됩니다.

Guix vs. NixOS 빌드 시스템 비교

커뮤니티에서는 Guix의 빌드 시스템이 Scheme으로 작성되어 이해하기 쉽고 명확하다는 평가가 많습니다. 반면 Nixpkgs는 Bash 스크립트 조각이 많고 `stdenv`를 불필요하게 상속하는 경우가 있어 복잡하다는 의견이 있습니다. Guix의 유용한 에러 메시지 또한 장점으로 언급되며, 빌드 시스템의 명확성이 Guix의 강점 중 하나로 꼽힙니다.

NixOS의 외부 바이너리 실행 철학

NixOS는 완전한 배포(Complete Deployments)를 지향하는 철학 때문에 외부에서 다운로드한 바이너리를 직접 실행하는 것을 권장하지 않습니다. 이는 시스템의 예측 가능성과 재현성을 높이기 위함입니다. 반면 Guix는 `bin-guix` 채널이나 `nix-ld`, `envfs`와 같은 도구를 통해 외부 바이너리 실행을 상대적으로 더 쉽게 지원하는 것처럼 보인다는 논의가 있습니다.

패키징 도구와 접근 방식

NixOS의 `autoPatchelfHook`은 동적 라이브러리 의존성 문제를 해결하는 데 유용하며, `steam-run`과 같은 도구는 게임 외에도 다양한 바이너리 실행에 활용될 수 있습니다. `nix-ld`와 `envfs`는 임의의 바이너리 실행 환경을 제공하는 데 효과적입니다. 이러한 도구들은 Guix와 Nix 모두에서 라이브러리 패치(Library Patching)를 통해 유사한 문제를 해결하려는 시도를 보여줍니다.