現在、一部のプライベートソースソフトウェアをNixフォークにパッケージ化しようとしています。アプリケーションは.deb
ファイルの束として配布され、ほとんどはアプリケーションの他の部分で利用可能なライブラリを含みます。
簡単にするために、app.deb
実際のアプリケーションが含まれており、lib.deb
アプリケーションに必要なライブラリが含まれているとします。
現在私は以下を持っています:
# default.nix
let
nixpkgs = fetchTarball "https://github.com/NixOS/nixpkgs/tarball/nixos-23.11";
pkgs = import nixpkgs {
config = { };
overlays = [ ];
};
in {
lib = pkgs.callPackage ./lib.nix { };
app = pkgs.callPackage ./app.nix { };
}
# lib.nix
{ lib, stdenv, autoPatchelfHook, dpkg, requireFile,
libcxx, libgcc, }:
stdenv.mkDerivation {
pname = "myapp-lib";
version = "1.0.0";
src = requireFile {
name = "lib.deb";
sha256 = "313e8686118ccba397de0bdfca101f1053b758227fd9d3510ea78644f2450bfe";
url = "https://softwarecorp.example/downloads";
};
nativeBuildInputs = [
dpkg
autoPatchelfHook
];
unpackPhase = "dpkg-deb -x $src .";
buildInputs = [ libcxx libgcc ];
installPhase = ''
cp -r lib $out/
'';
}
# app.nix
{ lib, stdenv, autoPatchelfHook, dpkg, requireFile,
libcxx, }:
stdenv.mkDerivation {
pname = "myapp-bin";
version = "1.0.0";
src = requireFile {
name = "app.deb";
sha256 = "f4abbdb3f83d982569c5cd30ce5ad63ec4e49011d165e17a2c59d9a613f163b9";
url = "https://softwarecorp.example/downloads";
};
nativeBuildInputs = [
dpkg
autoPatchelfHook
];
unpackPhase = "dpkg-deb -x $src .";
buildInputs = [ libcxx ];
installPhase = ''
cp -r bin $out/
'';
runtimeDependencies = [ myapp-lib ]; # <-- how to do this?
}
派生は独自に構築され、派生lib
に含まれる内容を追加したいと思います。app
ファイルの上部にある一般パッケージの依存関係リストに追加することはできません。また、この時点でパッケージをnixpkgsに送信することを避けたいと思います。なぜなら、アプリケーションを完全にパッケージ化できるかどうかはわかりませんし、完了できることがわかるまで、管理者として機能したくないからです。
あるいは、そのようなクローズドソースソフトウェアをパッケージ化して広範な派生を必要としないようにするための良いパターンはありますか?私が知る限り、ここのライブラリはすべて同じバージョンを持っており、会社の製品の他の場所では絶対に使用されていないので、ここに単一のフォークを構築することは許可されています。
答え1
ダブルブランチを防ぐために、ライブラリをパッケージ化せずinstallPhase
にpostUnpack
。
# app.nix
{
stdenv,
autoPatchelfHook,
dpkg,
requireFile,
libcxx,
}: let
myLib = requireFile {
name = "lib.deb";
sha256 = "313e8686118ccba397de0bdfca101f1053b758227fd9d3510ea78644f2450bfe";
url = "https://softwarecorp.example/downloads";
};
in
stdenv.mkDerivation {
pname = "myapp-bin";
version = "1.0.0";
src = requireFile {
name = "app.deb";
sha256 = "f4abbdb3f83d982569c5cd30ce5ad63ec4e49011d165e17a2c59d9a613f163b9";
url = "https://softwarecorp.example/downloads";
};
nativeBuildInputs = [
dpkg
autoPatchelfHook
];
unpackPhase = "dpkg-deb -x $src .";
postUnpack = ''
dpkg-deb -x ${myLib} .
cp -r lib $out/
'';
buildInputs = [libcxx];
installPhase = ''
cp -r bin $out/
'';
}
コンボepson-alc1100
これは実装の例です。
答え2
lib
まず、式の作成中に派生にアクセスできる必要がありますapp
。したがって、一番下の部分は、要素が互いに参照して引数として渡すことができる一連のdefault.nix
「再帰」を持つように変更する必要があります。lib
app
{
lib = pkgs.callPackage ./lib.nix { };
app = pkgs.callPackage ./app.nix { inherit lib; };
}
これで、というapp.nix
パラメータが必須ですが、lib
すでに追加したようです。 (実際には実際のコードはパラメータをpkgs.lib
提供するライブラリであり、名前の競合nixpkgs
なしに派生に使用できるため、パラメータの名前は異なると予想されます。)
これで、渡したいコレクションをapp.nix
作成するだけです。これはと同じです。つまり、派生した出力パスと同じ名前の環境変数を設定するという意味です。 (質問に書いた内容にもかかわらず、これが有効な主張だとは思わない。)inherit lib;
mkDerivation
lib = lib;
lib
lib
runtimeDependencies
mkDerivation
これで、Builderスクリプトでこれを作成するためにapp
必要なすべての操作を実行できます。たとえば、シンボリックリンクを作成できます。ここで実行したい操作の正確な詳細は、アプリケーションがそのライブラリを見つける方法の詳細によって異なります。lib
app
ln -s $out/lib $lib
現在のディレクトリでシンボリックリンクを実行してnix-build -A app
確認し、構築した内容を確認し、期待どおりに参照されていることを確認してください。result
lib