Build versus Runtime Abhängigkeiten in Nix

Question

Ich fange gerade an, mit Nix in Verbindung zu treten, so Entschuldigungen, wenn ich die Antwort auf meine Frage in den Dokumenten verpasste.

Ich möchte Nix verwenden, um eine sichere Produktionsmaschine mit dem minimalen Satz von Bibliotheken und ausführbaren Dateien einzurichten. Ich möchte keine Compiler oder andere Build-Tools, da dies Sicherheitsrisiken darstellen kann.

Wenn ich einige Pakete installiere, scheint es, dass sie nur von den minimalen Laufzeitabhängigkeiten abhängen. Zum Beispiel, wenn ich apache-tomcat-8.0.23 installiere, dann bekomme ich eine Java-Laufzeitumgebung (JRE) und die vorgefertigten JAR-Dateien, die Tomcat enthalten.

Auf der anderen Seite scheinen einige Pakete eine vollständige Build-Toolchain als Abhängigkeiten enthalten. Ein weiteres Java-basiertes Beispiel, wenn ich installiere spark-1.4.0 Nichts zieht das Java Development Kit (JDK), die einen Compiler enthält nach unten, und es zieht auch die Maven-Tool bauen usw.

So sind meine Fragen wie folgt:

1. Unterscheiden Do Nix-Pakete zwischen Build- und Laufzeitabhängigkeiten?
2. Warum scheinen einige Pakete von Build-Tools abhängig zu sein, während andere nur Laufzeit benötigen? Ist das alles darauf zurückzuführen, wie der Paketautor die Anwendung abgeschlossen hat?
3. Wenn ein Paket Build-Abhängigkeiten enthält, die ich nicht möchte, gibt es irgendetwas, was ich als Operator tun kann, außer meine eigene alternative Verpackung für die gleiche Anwendung zu entwerfen?

Vielen Dank.

Answer 1

1. Die Laufzeitabhängigkeiten sind eine Teilmenge der eingebauten Zeitabhängigkeiten, die Nix durch Abtasten des erzeugten Ausgabe für den Hash-Teil jedes build-Zeitabhängigkeiten Speicherpfad automatisch bestimmt. Wenn Sie beispielsweise ein Paket mit dem Compiler /nix/store/abcdef...-foo-1.20 erstellen, durchsucht Nix alle Dateien in der generierten Ausgabe nach dem Hash-Bit abcdef.... Wenn dieser Hash gefunden wird, wird angenommen, dass die Ausgabe den Compiler in irgendeiner Weise referenziert, so dass sie als Laufzeitabhängigkeit betrachtet wird. Wenn dieser Hash jedoch nicht auftritt, hat die generierte Ausgabe keinen Verweis auf den Compiler und kann daher nicht zur Laufzeit darauf zugreifen. Daher wird foo-1.20 als Nur-Build-Only-Abhängigkeit behandelt.

2. Einige Pakete zeichnen große Teile ihrer Build-Umgebung für Informations-/Debugging-Zwecke auf. Perl speichert zum Beispiel jedes Detail über die Tools, mit denen es kompiliert wird. Daher werden all diese Speicherpfade als Laufzeitabhängigkeiten behandelt, obwohl Perl sie zur Laufzeit nicht benötigt, aber Nix kann nicht wissen: es weiß nur, dass der Perl-Speicherpfad diese Tools verweist. Nun bemühen sich Nixpkgs-Betreuer in der Regel darum, das zu bereinigen, indem sie beispielsweise das Logfile, das all diese Speicherpfade von der Installation enthält, usw. beschneiden, aber es gibt sicher noch viele Pakete in der Datenbank, für die noch nicht optimiert wurde dieses Ende noch.

3. Angenommen, Sie möchten eine Version von openssh kompilieren, die nicht von PAM abhängig ist. Dann können Sie die Build-Eingabe mithilfe einer Außerkraftsetzung aus dem Ausdruck entfernen, d. H. Sie ersetzen das pam-Argument, das normalerweise an die openssh-Build-Funktion übergeben wird, durch null.Um das zu tun, speichern Sie die folgende Datei in ~/.nixpkgs/config.nix

   { 
       packageOverrides = super: let self = super.pkgs; in { 
       openssh-without-pam = super.openssh.override { 
        pam = null; 
       }; 
       }; 
   } 
   

   und jetzt dieses Paket installieren, indem Sie:

   $ nix-env -f "<nixpkgs>" -iA openssh-without-pam